Data integrity verification via a degraded key

Abstract

Disclosed are systems and methods for developing novel public / private key pairs with unique properties, whereby standard data security operations in existing data security infrastructures return data integrity verification results but do not provide the expected data security of such infrastructures. These novel keys are referred to as degenerate keys (112) and can be used to replace the public and private keys in existing public / private key cryptosystems. Since degenerate key data integrity verification can utilize existing data security infrastructures that have been widely implemented, such instances can be immediately applied and are configured to seamlessly transition back from an integrity-only mode to a security mode. In some examples, the degenerate key instances described herein can be employed during software testing and / or factory validation phases of product development to allow for data integrity verification before programming the developer's active (i.e., non-degenerate) keys into the product, thereby pairing software with hardware.

Description

BACKGROUND OF THE INVENTION

[0001] For example, data security, as implemented via various encryption methods including public key cryptography or asymmetric cryptography, is a useful tool in modern computer systems, applications, devices, and protocols. For instance, by encrypting a message using the public key of an authorized recipient, the message can be decrypted (thereby unlocking the actual content of the message) only using the recipient's complementary private key, which must be kept secure by the recipient. Many forms of encryption rely on complex mathematical operations, making it nearly impossible (at least within a feasible time scale) for an unauthorized third party to break the encryption.

[0002] In addition to data security, data integrity verification is also important in many modern computer systems, applications, devices, and protocols. Data integrity verification refers to the process of verifying the accuracy of underlying data, e.g., confirming that the data has not been accidentally altered within a given time period, regardless of who has access to / decrypts the true underlying value of the data or who sent the data. Thus, while data security attempts to control who can access the data, data integrity verification refers to the process of ensuring that the data accessed has the value it should have.

[0003] In a typical secure data transfer scenario, input data (e.g., a document or other electronic data image) can be digitally signed (e.g., in addition to optionally encrypting the content of the input data itself) by the owner of the input data and then sent to a recipient. A digital signature can be used to provide additional verification regarding the origin, identity, and / or status of the input data and can serve as a trustworthy indication of the signer's informed consent. To create a digital signature, the sending entity can use software to create a one-way hash of the input data to be signed. The hash can then be encrypted using the sender's private key. The encrypted hash of the input data, along with other optional information (e.g., the hash algorithm used), can be collectively referred to herein as a digital signature.

[0004] Subsequently, the recipient can use a digital signature verification process to ensure that the document has not been tampered with or modified in any way by a third party during transmission. For example, if a third party has changed even a single data bit in the input data, then it will hash to a different value with almost 100% certainty, allowing the recipient to determine that data integrity has not been maintained or that a private key corresponding to a public key not presented by the signer was used to create the digital signature. Instead, if the decrypted hash does match the hash of the same data calculated by the recipient, then it will prove that the data has not changed since it was initially signed by the sender, i.e., data integrity has been maintained.

[0005] In some instances, being able to perform a data integrity check on the first piece of input data may be more important than performing a full digital signature verification process on the input data (i.e., which also includes verifying the identity of the sender). In other instances, performing a full digital signature verification may not be needed at all. Thus, it may be desirable to have a system for performing a data integrity verification check that does not have to perform a full digital signature verification process, but still leverages an existing data security infrastructure to perform the data integrity verification check. SUMMARY OF THE INVENTION

[0006] The examples disclosed herein provide systems and methods for developing novel public / private key pairs with unique properties, whereby standard data security operations in an existing data security infrastructure return data integrity verification results, but do not provide the expected data security of such an infrastructure. Keys with this unique property are referred to herein as degenerate keys and can be used to replace the public and private keys in an existing public / private key cryptosystem. Degenerate keys can be configured to be used with several current public / private key authentication implementations that include, for example, the Rivest–Shamir–Adleman (RSA) cryptosystem for secure data transfer. Since the degenerate key data integrity verification examples disclosed herein can leverage an existing data security infrastructure that has been widely implemented, such examples can be immediately applied and configured to seamlessly transition from an integrity-only mode (i.e., a mode that performs data integrity verification but does not provide data security) back to a secure mode (i.e., a mode that will perform data integrity verification as well as provide data security) when needed.

[0007] In some instances, the degenerate key examples described herein can be employed during the software testing and / or factory verification phases of product development. That is, software build and testing can be completed by a developer using degenerate keys (i.e., that only provide data integrity checks) and then, for example, when the software and / or device has passed verification, firmware can be used to burn one or more programmable fields that can have values set once using only the developer's active key (i.e., an encryption key that has not been specifically modified to be a degenerate key as defined herein) for a board or other electronic device (e.g., using an electric fuse or other similar technology). After that process, the board or other device will reject any future data and / or programs that are not signed with a key that matches the key burned into it, effectively pairing the software with the hardware. Another advantage of the examples described herein is that they allow existing factory programming and verification workflows to remain unchanged, except for the specific digital signature algorithm used to generate the degenerate keys employed during the testing and / or verification phases of product development.

[0008] It is understood that while the techniques herein are mainly discussed in the context of degraded RSA keys, nothing in this disclosure is intended to limit these techniques to RSA-based public key cryptosystems. The fact is that the techniques discussed herein can be readily applied across a wide range of cryptosystems and encryption methods, including the Digital Signature Standard (DSS), ElGamal, and the like. The techniques discussed here can also be further applied to various types of data certificates, as well as to perform data integrity verification checks on secure, securable, non-secure, and / or general-purpose devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] For a detailed description of various examples, reference will now be made to the accompanying drawings, in which:

[0010] Figure 1 is a flowchart illustrating techniques for performing data integrity verification via the use of degraded keys in accordance with aspects of the present disclosure; and

[0011] Figure 2 is a block diagram of an example of a computing device in accordance with aspects of the present disclosure. DETAILED DESCRIPTION

[0012] As described above, in some instances, it may be desirable to perform a data integrity verification check on a document or another piece of input data (e.g., a digital certificate, such as an X.509 format certificate, or the like) without performing a full digital signature verification. Thus, in accordance with examples disclosed herein, techniques are presented for creating and utilizing so-called degraded keys (e.g., degraded RSA keys) to self-sign such documents or certificates.

[0013] More specifically, in accordance with the RSA cryptosystem algorithm, two distinct prime numbers, which will be referred to herein as prime1 (also referred to as 'p' in the RSA cryptosystem) and prime2 (also referred to as 'q' in the RSA cryptosystem), are multiplied together to determine the modulus value n for both the public key and the private key. Then, the public key exponent (also referred to as 'e' in the RSA cryptosystem) and the private key exponent (also referred to as 'd' in the RSA cryptosystem) are determined, in particular, using the Carmichael totient function, as further detailed (e.g.) in RSA Cryptography Standard, Version 2.1, RFC 3447.

[0014] The value of the public key exponent 'e' together with the above-mentioned modulus value n can be published as part of the public key. The value of the private key exponent 'd' will be kept secret as the private key exponent. The basic principle behind RSA encryption is that, while it is possible to find three very large positive integers e, d, and n such that for all integers m (where 0 ≤ m < n) performing modular exponentiation, the following equation holds:

[0015] (m e )d ≡ m (mod n), (Equation 1) (where the triple bar represents modular congruence),

[0016] Even if the values of 'e' and 'n' are known, it is extremely difficult for an unauthorized third party to determine 'd', that is, the value of the private key exponent.

[0017] In fact, the public key (containing the values of 'n' and 'e' as discussed above) is used to encrypt the plaintext message'm' into the ciphertext version 'c(m)' of the message according to the following equation:

[0018] c(m) = m e mod n, (Equation 2),

[0019] And the private key (containing the value of 'd' as discussed above) is used to decrypt the ciphertext 'c' back to the original plaintext message version'm(c)' of the ciphertext according to the following equation:

[0020] m(c) = c d mod n, (Equation 3).

[0021] According to some examples disclosed herein, a degenerate RSA key is a key in which the private key exponent 'e' and the public key exponent 'd' of the RSA algorithm are intentionally set to be equal to 1. Since the decrypted version of the ciphertext generated using the RSA algorithm is determined according to Equation 3 above, then by choosing the value of the private key exponent ('d') to be equal to 1, Equation 3 above simplifies to:

[0022] m(c) = c mod n, (Equation 4).

[0023] By choosing the size of the modulus n such that c < mod n, Equation 4 further simplifies to:

[0024] m(c) = c, (Equation 5).

[0025] In other words, the plaintext of the message is the same as the ciphertext of the message. If the public key exponent 'e' in Equation 2 above is set to be equal to 1, the same effect occurs. That is, by intentionally setting the values of the private key exponent and the public key exponent to be equal to 1, the original message value is equal to the encrypted value determined by the RSA algorithm, that is, the true value of the content is simply passed through by the algorithm without change. In this way, the typical security / encryption aspect of the RSA key is frustrated by using a degenerate key, and the creation and utilization of the degenerate key will be further described in detail below (for example, in the field of data integrity verification during software testing or factory verification phases).

[0026] Figure 1FIG. 0 is a flowchart illustrating a technique 100 for performing data integrity verification via utilization of a degraded key in accordance with aspects of the present disclosure. At step 102, the method begins by creating a standard cryptographic key (e.g., using the OpenSSL software library). The resulting key may be, for example, an RSA key of a desired number of bits (e.g., 4,096 bits).

[0027] Next, at step 104, it may be desirable to optionally convert the standard key generated at step 102 into a modifiable (e.g., human-readable) format, such as a formatted or plain text file. As described above, the creation of the degraded keys described herein may involve calibrated manipulation of one or more parameters of the resulting cryptographic key in order to remove security functionality and degrade the key. In some instances, for example, when the key created is an RSA key, the relevant parameters of the resulting RSA key may include: modulus (also referred to as 'n' in the RSA cryptosystem), public key exponent (also referred to as 'e' in the RSA cryptosystem), private key exponent (also referred to as 'd' in the RSA cryptosystem), prime1 (also referred to as 'p' in the RSA cryptosystem), prime2 (also referred to as 'q' in the RSA cryptosystem), exponent1 (or e1, determined by d mod (p - 1)), exponent2 (or e2, determined by d mod (q - 1)), and coefficient (determined by q -1 mod p). By converting the standard RSA key into a modifiable format, these individual parameters may be more easily manipulated and modified, for example, by a developer seeking to create a degraded RSA key for use in integrity verification checks during testing and / or factory validation.

[0028] Next, at step 106, the method may create a template for the degraded key. In some instances, a simple Abstract Syntax Notation One (ASN.1) template may be created to hold the degraded key information. According to some instances, at step 108, the process of populating the template for the degraded key may include, for example, copying the values of the modulus, prime1, prime2, and coefficient into the degraded key template according to a specified format. In some cases, it may be beneficial to, for example, remove any colons, continuation lines, and / or add a leading 0x in certain fields to further simplify the processing and manipulation of the degraded key template.

[0029] According to an example of the degraded RSA key disclosed herein, at step 110, the private and public key exponents and the values of e1 and e2 may each be set to a value of 1 and then also copied into the degraded key template. For reference, e1, e2, and the modulus are used in the Chinese Remainder Theorem (CRT) algorithm for efficient exponentiation and modular arithmetic. For example, these values may be defined as follows:

[0030] e1 = d mod (p - 1) (Equation 6),

[0031] e2 = d mod (q - 1) (Equation 7), and

[0032] Coefficient = q -1 mod p (Equation 8).

[0033] Therefore, by setting the private key exponent value 'd' to 1, the values of both e1 and e2 also become 1, and the value of the coefficient remains unchanged.

[0034] Next, at step 112, a degenerate key can be created based on a degenerate key template in a first format, where, as described above, the degenerate key is configured to be applied to first input data and return an unaltered version of the first input data. In some instances, at step 113, the degenerate key template can optionally be converted to a first binary format, e.g.,.DER format or other binary format. According to some preferred instances, a check can be performed as part of step 113 to confirm that there are no typos or errors introduced during the creation of the degenerate key in the first binary format from the degenerate key template.

[0035] Next, at step 114 (assuming any typos or errors have been corrected at step 113), a degenerate key can also optionally be created in a second format (e.g.,.PEM format or other ASCII-based format), where the creation of the key in the second format is based on the representation of the degenerate key in the first binary format. For example, a.PEM file is essentially a Base64-encoded version of the corresponding.DER-encoded file.

[0036] Next, at step 116, the degenerate key can be used to perform a data integrity verification test. In some instances, instead of signing a complete binary file (which can be extremely large), a secure hash function (e.g., SHA-1, SHA-256, SHA-512, etc.) can be used to take the extremely large binary file and create a smaller, fixed-size value called a hash. This hash is then the content that is actually signed in order to determine if the degenerate key is working properly. This hash value can be called a secure hash because while it is easy to compute the hash of any electronic input data, it is extremely difficult to find a second electronic input data that will produce the same hash value (i.e., in mathematical terms, the hash function is a many-to-one function). In other instances, the hash can be inserted at a specific part of a digital certificate or signature file, e.g., at a known, marked, or otherwise pre-specified location, such that it can be checked during the data integrity verification process.

[0037] Thus, according to some examples, at step 116, the method may confirm that the hash of the given piece of input data is seen in an unchanged form in the secure hash representation of the given piece of input data, i.e., the hash that has been signed with a degenerate key. For example, if the original computed hash of the given piece of input data is the same as the value of the secure hash, then it can be concluded that data integrity has been maintained. If instead the two hash values are different, then it can be determined that data integrity has not been maintained. As mentioned above, through the use of the degenerate key, this data integrity verification check of step 116 can be performed without also performing a full digital signature verification of the sender's identity.

[0038] In some examples, a system or process that utilizes the degenerate key described herein may check the public key field in the resulting degenerate key certificate (or signature file, or other data format in which the degenerate key may be stored or transmitted). If the type of the key is set to RSA, the public key exponent value is 1, and the signing device is designated as general purpose (GP) or securable, then it can act as a trigger for the device to locate the hash of the to-be-signed (TBS) certificate, e.g., at a designated part of the certificate, and then use it to verify the TBS field of the certificate. According to some examples, as desired, the code may also be configured to similarly verify other fields in the certificate (e.g., the expmod field and / or the object identifier (OID) of the algorithm) to see if any of those values are corrupted or otherwise modified.

[0039] As Figure 2 illustrated, device 200 includes a processing element, such as processor 205, which includes one or more hardware processors, where each hardware processor may have a single or multiple processor cores. Examples of processors include (but are not limited to) a central processing unit (CPU) or a microprocessor. Although Figure 2 not illustrated in, the processing element that makes up processor 205 may also include one or more other types of hardware processing components, such as a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and / or a digital signal processor (DSP). In some cases, processor 205 may be configured to execute programming instructions to perform the tasks described in connection with the steps of Figure 1

[0040] Figure 2 Illustrated memory 210 is operably and communicatively coupled to processor 205. Memory 210 may be a non-transitory computer-readable storage medium or a program storage device, which is configured to store various types of data, including program instructions that cause the processor to perform one or more programming actions. For example, memory 210 may include one or more volatile devices, such as random access memory (RAM). In some cases, Figure 1 ​The various degraded key templates, certificates, and / or keys mentioned in may be stored, at least temporarily, in the memory 210. The non-volatile storage device 220 may include one or more disk drives, optical disk drives, solid state drives (SSDs), tape drives, flash memories, electrically programmable read-only memories (EEPROMs), and / or any other type of memory designed to maintain data for a duration after a power outage or shutdown operation. The non-volatile storage device 220 may also be used to store programs that are loaded into the RAM when such programs are executed.

[0041] As is known to those of ordinary skill in the art, software programs can be developed, coded, and compiled in various computing languages for various software platforms and / or operating systems and then loaded and executed by the processor 205. In one example, the compilation process of a software program can convert program code written in a programming language into another computer language such that the processor 205 can execute the programming code. For example, the compilation process of a software program can produce an executable program that provides encoded instructions (e.g., machine code instructions) for the processor 205 to implement a specific, non-general, particular computing function.

[0042] After the compilation process, then, the encoded instructions can be loaded from the memory 220, from the memory 210, into the processor 205 and / or embedded within the processor 205 (e.g., via a cache or on-board ROM) as computer-executable instructions or process steps. The processor 205 can be configured to execute the stored instructions or process steps, i.e., to execute the instructions or process steps to transform the computing device into a non-general, particular, and special programmed machine or device. Stored data (e.g., data stored by the storage device 220) can be accessed by the processor 205 during the execution of the computer-executable instructions or process steps to direct one or more components within the computing device 200. The memory 220 can be partitioned or segmented into multiple sections that can be accessed by different software programs. For example, the memory 220 may include sections designated for specific purposes, such as storing program instructions or data for updating the software of the computing device 200. In one example, the software to be updated includes the ROM or firmware of the computing device. In some cases, the computing device 200 may include multiple operating systems. For example, the computing device 200 may include a general operating system for normal operation. The computing device 200 may also include another operating system, such as a boot loader, for performing specific tasks (e.g., upgrading and restoring the general operating system and allowing access to the computing device 200 at a level that is normally not available through the general operating system). Both the general operating system and the other operating system can access sections of the memory 220 designated for specific purposes.

[0043] One or more communication interfaces may include a radio communication interface for interfacing with one or more radio communication devices. In some cases, elements coupled to the processor may be included on hardware shared with the processor. For example, communication interface 225, memory 220, and memory 210 may be included, along with other elements such as a digital radio, in a single chip or package, such as in a system-on-chip (SOC). The computing device may also include an input device 230 and / or an output device (not shown), examples of which include sensors, cameras, human input devices (such as a mouse, keyboard, touch screen), monitors, displays, haptic or motion generators, speakers, lights, etc. For example, processed input from input device 230 may be output from computing device 200 via communication interface 225 to one or more other devices.

[0044] The foregoing discussion is intended to illustrate the principles of the disclosure and various embodiments. Once the foregoing disclosure is fully understood, many variations and modifications will become apparent to those of ordinary skill in the art. The following claims are intended to be construed to cover all such variations and modifications.

[0045] The techniques described in this disclosure may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the software may be executed in one or more processors, such as a microprocessor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), digital signal processor (DSP), etc. The software implementing the techniques may initially be stored on a computer-readable medium (such as a compact disc (CD), disk, tape, file, memory, or any other computer-readable storage device) and then loaded and executed in a processor. In some cases, the software may also be sold in the form of a computer program product that includes the computer-readable medium and the packaging material for the computer-readable medium. In some cases, the software instructions may be distributed via a removable computer-readable medium (such as a floppy disk, compact disc, flash memory, USB key), via a transmission path from a computer-readable medium on another digital system, etc.

[0046] In this description, the term "couple" or "couples" means an indirect or direct wired or wireless connection. Thus, if a first device is coupled to a second device, the connection may be through a direct connection or through an indirect connection via other devices and connections. The statement "based on" means "at least partially based on". Thus, if X is based on Y, then X may be a function of Y and any number of other factors.

[0047] Within the scope of the claims, modifications are possible in the described examples, and other embodiments are possible.

Claims

1. A method for creating a degenerate key, comprising: Creating a first encryption key, wherein the first encryption key includes a modulus value, a prime1 value, a prime2 value, and a coefficient value; Creating a template for a first degenerate key based on the first encryption key; Copying the modulus value, prime1 value, prime2 value, and coefficient value from the first encryption key into the first degenerate key template; Setting the values of the private key exponent, public key exponent, exponent1, and exponent2 to 1; Copying the values of the private key exponent, public key exponent, exponent1, and exponent2 into the first degenerate key template; Creating a first degenerate key based on the first degenerate key template in a first key format, wherein the first degenerate key is configured to be applied to first input data and return an unchanged version of the first input data; And Performing a data integrity verification test on the first input data using the first degenerate key.

2. The method according to claim 1, wherein the first encryption key is further created using an OpenSSL software library.

3. The method according to claim 1, wherein the first encryption key is further created using the Rivest-Shamir-Adleman (RSA) algorithm.

4. The method according to claim 3, wherein prime1 refers to the 'p' value in the RSA algorithm, wherein prime2 refers to the 'q' value in the RSA algorithm, wherein the private key exponent refers to the 'd' value in the RSA algorithm, wherein the public key exponent refers to the 'e' value in the RSA algorithm, and wherein the modulus refers to the 'n' value in the RSA algorithm.

5. The method according to claim 1, further comprising self-signing a first digital certificate using the first degenerate key.

6. The method according to claim 1, wherein the first input data includes a hash value.

7. The method according to claim 1, wherein the data integrity verification test is performed on the first input data during a software testing or factory verification phase.

8. A non-transitory program storage device, comprising instructions stored thereon to cause one or more processors to: Create a first encryption key, wherein the first encryption key includes a modulus value, a prime1 value, a prime2 value, and a coefficient value; Create a template for a first degenerate key based on the first encryption key; Copy the modulus value, prime1 value, prime2 value, and coefficient value from the first encryption key into the first degenerate key template; Set the values of the private key exponent, public key exponent, exponent1, and exponent2 to 1; Copy the values of the private key exponent, public key exponent, exponent1, and exponent2 into the first degenerate key template; Create a first degenerate key based on the first degenerate key template in a first key format, wherein the first degenerate key is configured to be applied to first input data and return an unchanged version of the first input data; and Perform a data integrity verification test on the first input data using the first degradation key.

9. The non-transitory program storage device according to claim 8, wherein the first encryption key is further created using the OpenSSL software library.

10. The non-transitory program storage device according to claim 8, wherein the first encryption key is further created using the RSA algorithm.

11. The non-transitory program storage device according to claim 10, wherein prime1 refers to the 'p' value in the RSA algorithm, prime2 refers to the 'q' value in the RSA algorithm, the private key exponent refers to the 'd' value in the RSA algorithm, the public key exponent refers to the 'e' value in the RSA algorithm, and the modulus refers to the 'n' value in the RSA algorithm.

12. The non-transitory program storage device according to claim 8, which further includes self-signing a first digital certificate using the first degradation key.

13. The non-transitory program storage device according to claim 8, wherein the stored instructions further cause the one or more processors to: Perform the data integrity verification test on the first input data during a software test or factory verification phase.

14. A system for creating a degradation key, the system comprising: A memory; And One or more processors operatively coupled to the memory, wherein the one or more processors are configured to execute non-transitory instructions that cause the one or more processors to: Create a first encryption key, wherein the first encryption key includes a modulus value, a prime1 value, a prime2 value, and a coefficient value; Create a template for a first degradation key based on the first encryption key; Copy the modulus value, prime1 value, prime2 value, and coefficient value from the first encryption key into the first degradation key template; Set the values of the private key exponent, public key exponent, exponent1, and exponent2 to 1; Copy the values of the private key exponent, public key exponent, exponent1, and exponent2 into the first degradation key template; Create a first degradation key based on the first degradation key template in a first key format, wherein the first degradation key is configured to be applied to first input data and return an unchanged version of the first input data; and Perform a data integrity verification test on the first input data using the first degradation key.

15. The system according to claim 14, wherein the first encryption key is further created using the OpenSSL software library.

16. The system according to claim 14, wherein the first encryption key is further created using the RSA algorithm.

17. The system according to claim 16, wherein prime1 refers to the 'p' value in the RSA algorithm, wherein prime2 refers to the 'q' value in the RSA algorithm, wherein the private key exponent refers to the 'd' value in the RSA algorithm, wherein the public key exponent refers to the 'e' value in the RSA algorithm, and wherein the modulus refers to the 'n' value in the RSA algorithm.

18. The system according to claim 14, further comprising self-signing a first digital certificate using the first degraded key.

19. The system according to claim 14, wherein the first input data includes a hash value.

20. The system according to claim 14, wherein the instructions further cause the one or more processors to: perform the data integrity verification test on the first input data during a software testing or factory verification phase.

Images