Data integrity verification via degraded keys

Abstract

Systems and methods for data integrity verification via degraded keys are disclosed whereby standard data security operations in existing data security infrastructure return data integrity verification results, but do not provide expected data security for such infrastructure. These novel keys are referred to as degraded keys (112) and may be used to replace the public and private keys in existing public / private key cryptographic systems. Because degraded key data integrity verification may utilize existing data security infrastructure that has been widely implemented, such instances may be applied immediately and configured to seamlessly transition from integrity-only mode to secure mode. In some examples, the degraded key instances described herein may be employed during software testing and / or factory verification phases of product development to allow data integrity verification prior to burning developer's activity (i.e., non-degraded) keys to the product to pair software with hardware.

Description

[0001] Information about divisional applications

[0002] This application is a divisional application. The parent application is an invention patent application filed on November 9, 2020, with application number 202080081934.6 and titled “Data Integrity Verification via Degenerate Keys.” Technical Field

[0003] Embodiments of the present disclosure relate generally to data integrity verification, and more particularly, to data integrity verification via degenerate keys. Background Art

[0004] For example, data security, as implemented through the use of various encryption methods, including public key cryptography or asymmetric cryptography, is a valuable tool in modern computer systems, applications, devices, and protocols. For example, by encrypting a message using the public key of an authorized recipient, the message can be decrypted (thus unlocking the actual contents of the message) using only the recipient's complementary private key, which must be kept safe by the recipient. Many forms of encryption rely on complex mathematical operations that make it nearly impossible for an unauthorized third party to break the encryption (at least within a practical timescale).

[0005] 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—for example, confirming that the data has not been accidentally altered within a given period of time, regardless of who has access to / decrypted the data's true underlying value or from whom it was sent. Thus, while data security attempts to control who can access data, data integrity verification is the process of ensuring that the data being accessed has the value it is supposed to have.

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

[0007] The digital signature verification process can then be used by the recipient 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 bit of data in the input data, it will then 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 other than the public key presented by the signer was used to create the digital signature. Alternatively, if the decrypted hash does match the hash of the same data calculated by the recipient, it will prove that the data has not been altered since it was originally signed by the sender, i.e., data integrity has been maintained.

[0008] 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, it may not be necessary to perform a full digital signature verification at all. Therefore, it may be desirable to have a system for performing data integrity verification checks that does not necessarily perform a full digital signature verification process, but that still leverages existing data security infrastructure to perform data integrity verification checks. Summary of the Invention

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

[0010] In some instances, the degenerate key examples described herein can be employed during the software testing and / or factory validation phases of product development. That is, software build and testing can be completed by the developer using a degenerate key (i.e., providing only a data integrity check), and then (e.g., once the software and / or device has passed validation) firmware can be used to burn one or more programmable fields with values ​​that are set only once for the board or other electronic device (e.g., using e-fuses or other similar techniques) using the developer's active key (i.e., an encryption key that has not been specifically modified to be a degenerate key, as defined herein). 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 validation workflows to remain unchanged, with the exception of the specific digital signature algorithm used to generate the degenerate key employed during the testing and / or validation phases of product development.

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

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

[0013] Figure 1 is a flow chart illustrating a technique for performing data integrity verification via utilization of a degenerate key according to aspects of the present disclosure; and

[0014] Figure 2 is a block diagram of an example of a computing device according to aspects of the present disclosure. DETAILED DESCRIPTION

[0015] 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 formatted certificate, or the like) without performing a full digital signature verification. Therefore, according to examples disclosed herein, techniques are presented for creating and utilizing so-called degenerate keys (e.g., degenerate RSA keys) to self-sign such documents or certificates.

[0016] More specifically, according to 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, in particular, the Carmichael function (Carmichael's totient function) is used to determine 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), as further detailed (for example) in RSA Cryptography Specification Version 2.1, RFC 3447.

[0017] 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 although three very large positive integers e, d, and n can be found such that for all integers m (where 0 ≤ m < n) performing modular exponentiation, the following equation holds:

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

[0019] 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.

[0020] 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:

[0021] c(m) = m e mod n, (Equation 2), 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:

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

[0023] 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 equal to 1. Since the decryption 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') equal to 1, Equation 3 above simplifies to:

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

[0025] By selecting the size of the modulus n such that c < mod n, Equation 4 is further simplified to:

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

[0027] 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 deliberately setting the private key exponent and the public key exponent values to be equal to 1, the original message value is equal to the encrypted value determined by the RSA algorithm, i.e., the true value of the content is simply passed through by the algorithm unchanged. 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 described in further detail below (e.g., in the field of data integrity verification during software testing or factory validation phases).

[0028] Figure 1 is a flowchart illustrating a technique 100 for performing data integrity verification via the use of a degenerate key according to aspects of the present disclosure. At step 102, the method begins by creating a standard encryption key (e.g., by using the OpenSSL software library). The resulting key can be, for example, an RSA key of a desired number of bits (e.g., 4,096 bits).

[0029] 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 plaintext file. As described above, the creation of the degenerate key described herein may involve calibrated manipulation of one or more parameters of the generated encryption key in order to remove security functionality and degenerate the key. In some instances, for example, when the created key is an RSA key, the relevant parameters of the generated 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 can be more easily manipulated and modified, for example, by a developer seeking to create a degenerate RSA key for use in integrity verification checks during testing and / or factory validation.

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

[0031] According to the example of degenerate RSA keys disclosed herein, at step 110, the private and public key exponents, as well as the values ​​of e1 and e2, can each be set to 1 and then copied into the degenerate key template. For reference, e1, e2, and the modulus are used in the Sunzi Remainder Theorem (CRT) algorithm for efficient exponent and modulus operations. For example, these values ​​can be defined as follows:

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

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

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

[0035] Therefore, by setting the private key exponent value 'd' to 1, the values ​​of both e1 and e2 also become 1, and the values ​​of the coefficients do not change.

[0036] Next, at step 112, a degenerate key can be created based on the degenerate key template in the first format, where, as described above, the degenerate key is configured to be applied to first input data and return an unchanged version of the first input data. In some examples, at step 113, the degenerate key template can optionally be converted to a first binary format, such as a .DER format or other binary format. According to some preferred examples, 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.

[0037] Next, at step 114 (assuming any typos or errors have been corrected at step 113), a degenerate key may also be optionally 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.

[0038] Next, at step 116, a data integrity verification test can be performed using the degenerate key. In some instances, instead of signing the full 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 what is actually signed to determine if the degenerate key is working properly. This hash value can be called a secure hash because, while it is easy to calculate 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, a hash function is a many-to-one function). In other instances, the hash can be inserted at a specific portion of the digital certificate or signature file, for example, at a known, marked, or otherwise pre-designated location, so that it can be checked during the data integrity verification process.

[0039] Therefore, according to some examples, at step 116, the method can confirm that the hash of the given piece of input data is seen in its unaltered form within its secure hash representation, i.e., the hash signed by the degenerate key. For example, if the originally calculated hash of the given piece of input data is identical to 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.

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

[0041] like Figure 2 As illustrated in FIG, device 200 includes a processing element, such as processor 205, which includes one or more hardware processors, each of which 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 2Although not illustrated in the figure, the processing elements comprising 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 programmed instructions to perform operations in conjunction with Figure 1 The steps describe the task.

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

[0043] Those skilled in the art will appreciate that software programs can be developed, coded, and compiled in various computing languages ​​for various software platforms and / or operating systems and subsequently 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 so that the programming code can be executed by the processor 205. For example, the compilation process of a software program can produce an executable program that provides coded instructions (e.g., machine code instructions) to the processor 205 to implement specific, non-general, specialized computing functions.

[0044] After the compilation process, the coded instructions can then be loaded from memory 220, memory 210, into processor 205 and / or embedded within processor 205 (e.g., via a cache or onboard ROM) as computer-executable instructions or process steps. 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 purpose, specific, and specially programmed machine or device. Stored data (e.g., data stored by storage device 220) can be accessed by processor 205 during the execution of the computer-executable instructions or process steps to instruct one or more components within computing device 200. Memory 220 can be partitioned or divided into multiple sections accessible by different software programs. For example, memory 220 may include sections designated for specific purposes, such as storing program instructions or data for updating the software of computing device 200. In one example, the software to be updated includes the computing device's ROM or firmware. In some cases, computing device 200 may include multiple operating systems. For example, computing device 200 may include a general-purpose operating system for normal operation. The computing device 200 may also include another operating system, such as a boot loader, for performing specific tasks, such as upgrading and restoring the general-purpose operating system and allowing access to the computing device 200 at a level not normally available through the general-purpose operating system. Both the general-purpose operating system and the other operating system can access sections of the memory 220 designated for specific purposes.

[0045] The one or more communication interfaces may include a radio communication interface for interfacing with one or more radio communication devices. In some cases, the 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 in a single chip or package along with other elements such as a digital radio, such as in a system on a chip (SOC). The computing device may also include input devices 230 and / or output devices (not shown), examples of which include sensors, cameras, human input devices (such as a mouse, keyboard, touch screen), monitors, display screens, tactile or motion generators, speakers, lights, etc. For example, processed input from input device 230 may be output from computing device 200 to one or more other devices via communication interface 225.

[0046] The above discussion is intended to illustrate the principles and various embodiments of the present disclosure. Once the above disclosure is fully understood, many variations and modifications will become apparent to those skilled in the art. The following claims are intended to be interpreted as covering all such variations and modifications.

[0047] 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, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), or the like. The software implementing the techniques may initially be stored in a computer-readable medium (e.g., a compact disc (CD), a disk, a tape, a file, a 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 comprising the computer-readable medium and packaging materials for the computer-readable medium. In some cases, the software instructions may be distributed via removable computer-readable media (e.g., a floppy disk, an optical disc, a flash memory, a USB key), via a transmission path from a computer-readable medium on another digital system, or the like.

[0048] Throughout this description, the term "couple" or "couples" means an indirect or direct wired or wireless connection. Thus, if a first device couples 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 "based at least in part on." Thus, if X is based on Y, X can be a function of Y and any number of other factors.

[0049] Modifications are possible in the described examples, and other implementations are possible, within the scope of the claims.

Claims

1. A method comprising: creating a first key, wherein the first key comprises a first plurality of values; creating a template for a second key based on the first key; copying the first plurality of values ​​from the first key into the template for the second key; Set the second multiple value to 1; copying the second plurality of values ​​into the template for the second key; creating the second key based on the template of the second key in a key format, wherein the second key is configured to be applied to first input data and return an unchanged version of the first input data; and A data integrity verification test is performed on the first input data using the second key.

2. The method of claim 1, wherein the first key is further created using the OpenSSL software library.

3. The method of claim 1, wherein the first key is further created using a Rivest-Shamir-Adelman (RSA) algorithm.

4. The method of claim 3 , wherein a first value in the first plurality of values ​​refers to a ‘p’ value in the RSA algorithm, wherein a second value in the first plurality of values ​​refers to a ‘q’ value in the RSA algorithm, wherein a first value in the second plurality of values ​​refers to a ‘d’ value in the RSA algorithm, wherein a second value in the second plurality of values ​​refers to an ‘e’ value in the RSA algorithm, and wherein a third value in the first plurality of values ​​refers to an ‘n’ value in the RSA algorithm.

5. The method of claim 1, further comprising self-signing a first digital certificate using the second key. The method of claim 1 , wherein the first input data comprises a hash value. The method of claim 1 , wherein the data integrity verification test is performed on the first input data during a software testing or factory verification phase.

8. The method of claim 1 , further comprising using the second key to self-sign a first digital certificate, wherein the first digital certificate comprises a hash value; The data integrity verification test includes: The triggering device locates the hash of the TBS certificate to be signed at a specified portion of the first digital certificate, and then uses the hash of the TBS certificate to verify the TBS field of the first digital certificate.

9. A non-transitory program storage device comprising instructions stored thereon to cause one or more processors to: creating a first key, wherein the first key comprises a first plurality of values; creating a template for a second key based on the first key; copying the first plurality of values ​​from the first key into the template for the second key; Set the second multiple value to 1; copying the second plurality of values ​​into the template for the second key; creating the second key based on the template of the second key in a key format, wherein the second key is configured to be applied to first input data and return an unchanged version of the first input data; and A data integrity verification test is performed on the first input data using the second key.

10. The non-transitory program storage device of claim 9, wherein the first key is further created using an OpenSSL software library.

11. The non-transitory program storage device of claim 9, wherein the first key is further created using an RSA algorithm.

12. The non-transitory program storage device of claim 11 , wherein a first value in the first plurality of values ​​refers to a ‘p’ value in the RSA algorithm, wherein a second value in the first plurality of values ​​refers to a ‘q’ value in the RSA algorithm, a first value in the second plurality of values ​​refers to a ‘d’ value in the RSA algorithm, wherein a second value in the second plurality of values ​​refers to an ‘e’ value in the RSA algorithm, and wherein a third value in the first plurality of values ​​refers to an ‘n’ value in the RSA algorithm.

13. The non-transitory program storage device of claim 9, wherein the stored instructions further cause the one or more processors to self-sign a first digital certificate using the second key.

14. The non-transitory program storage device of claim 9, wherein the stored instructions further cause the one or more processors to: The data integrity verification test is performed on the first input data during a software testing or factory verification phase.

15. A system comprising: Memory; and one or more processors operably 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: creating a first key, wherein the first key comprises a first plurality of values; creating a template for a second key based on the first key; copying the first plurality of values ​​from the first key into the template for the second key; Set the second multiple value to 1; copying the second plurality of values ​​into the template for the second key; creating the second key based on the template of the second key in a key format, wherein the second key is configured to be applied to first input data and return an unchanged version of the first input data; and A data integrity verification test is performed on the first input data using the second key.

16. The system of claim 15, wherein the first key is further created using an OpenSSL software library.

17. The system of claim 15, wherein the first key is further created using an RSA algorithm.

18. The system of claim 17, wherein a first value in the first plurality of values ​​refers to a 'p' value in the RSA algorithm, wherein a second value in the first plurality of values ​​refers to a 'q' value in the RSA algorithm, wherein a first value in the second plurality of values ​​refers to a 'd' value in the RSA algorithm, wherein a second value in the second plurality of values ​​refers to an 'e' value in the RSA algorithm, and wherein a third value in the first plurality of values ​​refers to an 'n' value in the RSA algorithm.

19. The system of claim 15, wherein the one or more processors are further configured to execute the non-transitory instructions to cause the one or more processors to self-sign a first digital certificate using the second key.

20. The system of claim 15, wherein the first input data comprises a hash value.

21. The system of claim 15, wherein the instructions further cause the one or more processors to: The data integrity verification test is performed on the first input data during a software testing or factory verification phase.

22. A method comprising: creating a template for a second key based on the first key; copying a first plurality of values ​​from the first key into the template of the second key; Set the second multiple value to 1; copying the second plurality of values ​​into the template for the second key; creating the second key based on the template of the second key; and A data integrity verification test is performed using the second key.

23. The method of claim 22, further comprising creating the first key using an OpenSSL software library.

24. The method of claim 22, further comprising creating the first key using a Rivest-Shamir-Adelman (RSA) algorithm.

25. The method of claim 24, wherein the first value in the first plurality of values ​​refers to a 'p' value in the RSA algorithm, wherein the second value in the first plurality of values ​​refers to a 'q' value in the RSA algorithm, wherein the first value in the second plurality of values ​​refers to a 'd' value in the RSA algorithm, wherein the second value in the second plurality of values ​​refers to an 'e' value in the RSA algorithm, and wherein the third value in the first plurality of values ​​refers to an 'n' value in the RSA algorithm.

26. The method of claim 22, further comprising converting the first key into a modifiable format.

27. The method of claim 22, further comprising self-signing a first digital certificate using the second key.

28. The method of claim 27, wherein the first digital certificate comprises a hash value, and wherein performing the data integrity verification test comprises: causing a hash of the TBS certificate to be signed to be identified at a designated portion of the first digital certificate; and The TBS field of the first digital certificate is verified using the hash of the TBS certificate.

29. The method of claim 22, wherein the template for the second key is based on Abstract Syntax Notation One (ASN.1).

30. The method of claim 22, wherein creating the second key comprises creating the second key in a first format, and wherein the first format is a .DER format.

31. The method of claim 30, further comprising converting the second key to a second format, wherein the second format is a .PEM format.

32. A system comprising: a memory configured to store instructions; and One or more processors configured to execute the instructions to: creating a template for a second key based on the first key; copying a first plurality of values ​​from the first key into the template of the second key; Set the second multiple value to 1; copying the second plurality of values ​​into the template for the second key; creating a second key based on the template of the second key; and A data integrity verification test is performed using the second key.

33. The system of claim 32, wherein the one or more processors are further configured to execute the instructions to create the first key using an OpenSSL software library.

34. The system of claim 32, wherein the one or more processors are configured to execute the instructions to create the first key using an RSA algorithm.

35. A system according to claim 34, wherein the first value of the first plurality of values ​​refers to the 'p' value in the RSA algorithm, wherein the second value of the first plurality of values ​​refers to the 'q' value in the RSA algorithm, wherein the first value of the second plurality of values ​​refers to the 'd' value in the RSA algorithm, wherein the second value of the second plurality of values ​​refers to the 'e' value in the RSA algorithm, and wherein the third value of the first plurality of values ​​refers to the 'n' value in the RSA algorithm.

36. The system of claim 32, wherein the one or more processors are further configured to execute the instructions to convert the first key into a modifiable format.

37. The system of claim 32, wherein the one or more processors are further configured to execute the instructions to self-sign a first digital certificate using the second key.

38. The system of claim 37, wherein the first digital certificate comprises a hash value, and wherein to perform the data integrity verification test, the one or more processors are configured to execute the instructions to: causing a hash of the TBS certificate to be signed to be identified at a designated portion of the first digital certificate; and The TBS field of the first digital certificate is verified using the hash of the TBS certificate.

39. The system of claim 32, wherein the template for the second key is based on Abstract Syntax Notation One (ASN.1).

40. The system of claim 32, wherein to create the second key, the one or more processors are configured to execute the instructions to create the second key in a first format.

41. The system of claim 40, wherein the one or more processors are configured to execute the instructions to convert the second key from the first format to a second format.

Images