JP4937921B2 - A secure interface for generic key derivation function support - Google Patents

Description

  The present invention relates generally to the field of cryptography. In particular, the present invention relates to providing versatile key derivation function support.

  Diffie-Hellman (DH) key sharing is a fundamental development in cryptography. It is the first working method of public key cryptography, which makes it possible to implement key distribution without setting a secret agreed upon in advance.

In the simplest form of DH key sharing, the parties have private keys x and y, respectively, from which public keys α ^x and α ^y can be derived, respectively. By exchanging the public key, each party can calculate the shared secret key α ^xy by combining the private key and the public key. The function used to derive the public key from the private key is a one-way function, and in the one-way function, the calculation of the public key is relatively simple, but the private key is extracted from the public key. Is infeasible. Such a function is based on the difficulty of factoring a large number that is the product of two large prime numbers, or a discrete logarithm problem over a finite field.

  Diffie-Hellman (DH) key sharing is widely used today. The IPSec protocol uses DH key agreement, which in most businesses allows employees to connect to remote offices on the public Internet and to connect to corporate networks from remote locations. Used in most of the virtual private networks (VPNs) used.

  Diffie-Hellman key agreement is also a NIST recommended option in the Transport Layer Security (TLS) protocol. The TLS protocol is a successor protocol of the SSL protocol. These protocols are now widely used to secure the flow of communication data on the web that requires careful handling, such as online banking.

  Static DH key sharing is a variant of DH key sharing where one of the private keys is static, meaning that it is a long-term key that is used multiple times.

  Because of the sensitivity of private keys, it is usually located in a private key module, which is a practice involving private key operations, especially when used multiple times. In general, such modules contain means to prevent private key extraction and, to a more limited extent, prevent misuse of private key operations. For example, these modules can be implemented in specialized hardware that does not allow the loading of malicious software such as viruses, worms, and Trojan horses. In general, the practice of such tamper prevention measures is expensive. Therefore, modules are typically designed to have minimal functionality in order to reduce costs. As described above, the minimum function requires protection by preventing falsification.

  In a simple example, the module may be a smart card. The smart card is carried by the user. Suppose a user wants to connect securely from a remote computer to a destination such as a home computer. The user places the smart card in a smart card reader attached to the remote computer. Thereafter, connection to the home computer is performed. The home computer authenticates the user by sending a question. The remote computer forwards the question to the smart card. The smart card signs the inquiry, which is transferred back to the home computer. The home computer verifies the question and provides the user with the necessary access via the remote computer. This allows the user to move around between different remote computers. However, the remote computer must not be able to extract the user's private key from the smart card. That is, the remote computer can only connect to the home computer while the user has the smart card in the reader. (To achieve this, more sophisticated methods are needed than simple questions and responses, and smart cards can authenticate traffic or even encrypt and decrypt all traffic. It may be necessary.)

  To further enhance security, a key derivation function (KDF) is often specified, which is a one-way function applied to the raw DH shared secret. Certain standards specify that KDF be used with DH key sharing. However, the recommended KDF differs for different standards. For example, ANSI specifies several different KDFs, such as IEEE, SSL and TLS, and IPSec is also different.

  The details of the two standardized key derivation functions are briefly described below. These are ANSI X9.63 key derivation and TLS key derivation functions.

  ANSI X9.63 key derivation is calculated as follows: The input has three components. The first input component is Z, which is a secret value shared between the private key module and the connection destination, for example, the home computer in the simple example above. This shared secret value Z should not be revealed to any gateway, such as the remote computer in the above example. The second input component is the integer key datalen, which is the length in octets of the keying data to be generated. An optional third input component is an octet string SharedInfo, which is composed of some data shared by entities sharing the shared secret value Z. In addition, SharedInfo is also optionally given an Abstract Syntax Notation 1 (ASN.1) encoding, which includes five fields: an algorithm identifier, an optional identifier for each of the two entities, and optional public shared information. , And optional private sharing information. KDF evaluation for this input then proceeds as follows.

  The first step of the ANSI X9.63 key derivation function is a consistency check, which is performed on the input length and the desired output length keydatalen. Thereafter, the 4-octet integer counter j is initialized with the value 1. A series of hash values Kj is calculated as follows. Kj = SHA-1 (Z‖j‖ [SharedInfo]), where ‖ indicates concatenation, and [] indicates that the input enclosed in parentheses is optional. The number t of these outputs depends on keydatalen. The hash values are concatenated into an octet string K ′ = K1‖K2‖. . . ‖Kt is formed. The octet string is truncated to the short octet string K by taking the leftmost keydatalen octet. The output of ANSI X9.63 KDF is K.

  In the TLS standard, the key derivation function is referred to as a pseudorandom function (PRF). The structure of the TLS PRF is completely different from ANSI X9.63 KDF and is given as follows. This configuration uses the auxiliary configuration HMAC described first.

  The HMAC configuration can be built on any hash function. When the HMAC configuration is used with hash functions such as MD5 and SHA-1, the resulting function is named HMAC-Hash, where Hash is the name of the hash function. TLS PRF uses HMAC-SHA-1 and HMAC-MD5. The general form of HMAC, namely HMAC-Hash, operates as follows.

The input to the HMAC is a secret key K and a message M. The output is a tag T. The HMAC tag is calculated as T = Hash (C + K‖Hash ((D + K) ‖M)), where ‖ represents a concatenation and + is the well-known bitwise exclusive OR (XOR) operation. C and D are constant bit strings determined by the HMAC algorithm. More precisely, the key K is padded with zero bits until its length is C and D, but it is excluded when K is longer than C and D, in which case K is a hash of the key and Replaced. This is described as follows.
T = HAMC-Hash (K, M)

The function HMAC-Hash is used for another auxiliary hash general configuration in the TLS PRF called P_Hash. The configuration of P_Hash is as follows.
P_Hash (Z, seed) = HAMC-Hash (Z, A (1) ‖ seed) ‖ HMAC-Hash (Z, A (2) ‖ seed) ‖ HMAC-Hash (Z, A (3) ‖ seed). . .
Here, ‖ represents concatenation, and A () is defined as follows.
A (0) = seed; A (j) = HMAC_Hash (Z, A (j−1))

  P_Hash can generate the required amount of data by repeating the required number of times. Similar to ANSI X9.63, if the resulting concatenation of the HMAC tag is longer than the required amount of data, the last (rightmost) byte is cut off.

The TLS PRF is defined as follows:
PRF (Z, label, seed) = P_MD5 (S1, label ‖ seed) + P_SHA-1 (S2, label シ ー ド seed)
Here, as usual, + represents exclusive OR, and ‖ represents concatenation. The values S1 and S2 are obtained by splitting the octet string secret Z in half, the left half is S1, the right half is S2, the left half is large, and the secret has an odd number of octets.

  As specified by the algorithm, the output of MD5 is 16 octets, while the output of SHA-1 is 20 octets, and the function P_MD5 typically uses more iterations than P_SHA-1. .

  TLS PRF is widely used in the TLS protocol. For example, it is used to derive a master secret from a pre-master secret, and is used to derive an encryption key from a master key.

  The discrepancy in standards for KDF has created a great incentive for module practitioners to either support DH key sharing without KDF or simply support a limited number of KDFs.

  Standard Public Key Cryptography Standard (PKCS) # 11: Cryptographic token interface (cryptoki) addresses a token interface, such as a smart card, which is a class of private key modules. In this standard, a few KDFs are supported, but the provided interface is generally not adaptable to KDF. Standard FIPS 140-2 also specifies conditions for private key modules. It explicitly requires that cryptographic values, such as raw DH shared secret values, must not leave the private key module's secure boundary, but does not provide an accurate mechanism for key derivation.

  The inventors of the present invention have discovered that improper reuse of static DH private keys can ultimately result in replay of private keys by adversaries. More precisely, if a shared secret established via static DH key sharing is used without applying a key derivation function (KDF), the adversary can use several different shared keys established and used. Attack can be launched, thereby regenerating the static DH private key.

  The recent discovery of the inventor of the present invention means that there is a choice of being able to practice DH without KDF can be a safety risk. Supporting a reduced number of KDFs is too restrictive. For example, a hardware upgrade may be required only to use a new application standard.

  Since the standards do not match for the key derivation function, the module that performs DH private key operations must support some different KDF standards to some extent. One approach is that the module implements all KDF algorithms, but it is expensive because the module must support multiple different KDFs, and the module will replace them when a new KDF appears. Limited because it cannot be supported. The opposite approach is to provide unprotected access to the raw DH private key operations and allow the application using the module to apply KDF. However, this makes private keys vulnerable to recently discovered attacks.

  The object of the present invention is to eliminate or mitigate the above disadvantages.

  Generally speaking, the present invention allows a module to execute part of the KDF algorithm, as shown by the application that uses the module. This eliminates the need for the module to practice the entire KDF for each required KDF. Instead, only the reusable part common to most KDFs is practiced. Furthermore, when new KDFs are needed, they can be supported if they are built on the part of the KDF that the module has implemented.

  Thus, raw access to static DH private key operations is generally disallowed on modules because security risks tend to be too high. Instead, the module provides an interface that is flexible enough to support all existing interesting KDFs, as well as all foreseeable KDFs. This is done by practicing the intersection of existing and foreseeable KDFs on the secure private key module. Most KDFs today are built on a hash function. Previously, most private key modules had to implement at least a hash function. This is also important for considering falsification prevention, as hash functions are very important for the security of many algorithms, such as digital signatures.

  As an alternative to this, the module can also easily provide access to the SHA-1 compression function. An application can use this compression function to calculate SHA-1 simply by doing some necessary padding and doing some appropriate chaining. This further simplifies the practice module and increases its adaptability. For example, some additional flexibility is that some ANSI deterministic random number generators use the SHA-1 compression function instead of the entire function SHA-1. More generally, random number generation, such as key derivation, typically involves a combination of hash function value computation methods for a mixture of secret and non-secret inputs. Thus, the present invention is not limited to supporting multiple KDFs, but can also support multiple deterministic random number generators.

  For even greater flexibility, the module can support smaller operations, such as some of the sub-operations of the SHA-1 compression function. However, these sub-operations are not expected to be reused for some purpose other than the SHA-1 compression function. Also, these individual sub-operations do not provide the full security of SHA-1, and thus may reveal the secret on the module to the application, which must be avoided. However, the exception to this principle is two pairs of new hash functions. This is a pair of SHA-384 and SHA-512 and a pair of SHA-224 and SHA-256. Each of these pairs has many common parts and can essentially be implemented with a single common function. The application processes the input and output only for the common function to obtain the desired hash function.

  In TLS terminology, two hash functions are used in the case of TLS key derivation known as a pseudo-random function (PRF). One is SHA-1 and the other is MD5. In order to apply PRF-TLS to secret Z, the secret is halved into two parts S1 and S2. Then, a PRF based on MD5 is applied to S1, and a function based on SHA1 is applied to S2. The module provides a mechanism for revealing S1 to the application and keeps S2 in the module so that the module does not have to do both MD5 and SHA1, which can be expensive. The module calculates SHA1 for S2, and the application can calculate MD5 for S1.

  Other KDFs other than one in the TLS are not expected to divide the secret in that way, but tend to be difficult to predict in which direction the standard will go in the future. Therefore, it is useful for the module to support a general way of splitting secrets. Thus, the interface to the module includes a mechanism that allows the application to request that part of the secret be published. The module is practiced in such a way that enough secrets remain secret and the application cannot make multiple requests for different parts of the secret.

  As new standards continue to emerge, and as standards continue to redesign KDF and random number generators, they are adaptable to hardware modules, and a secure interface increases module availability. To provide important value. Otherwise, there is a risk that the module will be discarded too quickly.

  The following description and the embodiments described therein are provided by way of illustration of specific embodiments of the principles of the invention. These examples are provided for purposes of illustrating those principles of the invention and are not limiting. In the following description, like parts are denoted by like reference numerals throughout the specification and the drawings.

  Referring to FIG. 1, a connection between a user device 40 and a connection destination 100 protected by a private key module device 50 is shown. The connection between the user device 40 and the connection destination 100 is generally not secure and is open. For example, the connection includes a link 70 to a public network 80 such as the Internet and a link 90 from the public network to the connection destination 100. Each link may be a wired link, a wireless link, or a combination of both. Typically, the private key module device 50 is a self-contained device that can be inserted into a local device, such as a smart card or token, or a user device 40 on which an application is launched. When the module device 50 is activated by an application, it cooperates with the user device 40 to protect communications on the link 70.

  In this operation mode, the private key module device 50 provides a private key function for protecting the connection between the user device 40 and the connection destination device 100. However, since the private key module device 50 is a custom private key module, it requires some additional protection that is separate from the protection of a typical user computer such as the user device 40. Security is enhanced by practicing the key derivation function (KDF) partly in an application running on the user device 40 and partly in a module running on the private key module device 50. . Although user device 40 and private key module device 50 are described herein as separate devices, it will be understood that they can be integrated into a single physical device. For example, the private key module device 50 can reside on the user device 40 as a special embedded chipset.

  The user device 40 typically starts a plurality of applications and performs different functions using the CPU 42 and the memory device 44. The user device 40 includes a communication module 45 for managing the link 70 under the command of a communication application running on the CPU 42. In order to establish secure communication, the communication application implements an established protection protocol, such as one of the protocols discussed above, that requires a private key function such as KDF. In order to facilitate computation of the selected KDF while maintaining flexibility, the derivation of the KDF is separated into discrete subroutines, and a subroutine that requires operation on a private key is executed by the private key module 50. . Balanced by the user device 40 so that unprocessed private key data is not accessed through the user device 40.

  Referring to FIG. 2, a key derivation function (KDF) that is partially practiced in the application 10 running on the user device 40 and partly practiced in the application 20 running on the private key module 50 is shown. A practical example of a protection system is shown. The KDF is divided into two parts. Private key module 50 generates KDF components 24, and application 10 uses these components to calculate KDF balance 22. The private key module 20 has a module interface 26 that exchanges data and communicates with the application 10. The module interface 26 further has two interface functions, a first interface function 28 and a second interface function 30.

  Advantageously, certain secret values, such as the Diffie-Hellman shared secret value Z, are determined within the private key module 20. The length of Z is known to the application 10, but the value of Z is not known. The application 10 has a handle so that it can reference the secret Z and thus ask the private key module 20 to derive a value from Z.

  The first interface function 28 has an input consisting of an integer and a secret Z handle. This integer defines the number of Z octets disclosed to the application 10. This is the S1 value in the TLS PRF. When performing this function, the private key module 20 can keep the minimum number of secret octets as S2, so that the application 10 does not know the overall secret. This minimum number is chosen appropriately for the intended protection level of the application. It may be 10 octets for an 80 bit protection level. Once the first interface function 28 is called, the secret is permanently disconnected to S2, and the private key module 20 does not allow further disconnection of S2. A handle or pointer for referring to S2 is provided in the application 10. Preferably, the handle or pointer referring to Z is reused because Z is not used in further calculations. Thereafter, the private key module 20 sets the secret Z = S2 after the first interface function 28 is called. Optionally, private key module 20 can simply create a new handle pointing to S2 and output this new handle to application 10 so that application 10 can later reference S2. The value S1 is always part of the output of the first interface function 28, so that the application 10, i.e. the first part 22 of the KDF included in the application 10, is like the MD5 calculation used in the TLS PRF. Any necessary calculations can be performed on S1.

The second interface function 30 has an input composed of two values X and Y and a secret Z handle. The first value is an octet string of the same length as the secret Z. The output of the second interface function 30 is as follows.
SHA-1 (X + Z‖Y)

  The second interface function 30 is a basic cryptographic operation that can be constructed by both ANSI X9.63 KDF and TLS PRF. From the output S1 of the first interface function 28 and the output of the second interface function 30, that is, the hash value of SHA-1, the application 10 can complete the KDF calculation and derive the key.

  The user device 40 generally has a CPU 42, a memory device 44 accessible to the CPU 42, a storage medium 46 which is also accessible to the CPU 20, and certain input and output devices (not shown). As will be appreciated, the user device 40 may be other programmable computing devices. The application 10 is executed on the CPU 42. The application 10 may be stored on the storage medium 46 and may be permanently installed on the user device 40, may be removed from the user device 40, or may be remotely accessible to the user device 40. The application 10 can also be directly mounted on the CPU 42. The output of KDF is necessary to protect the connection from the user device 40 to the connection destination 100.

  The private key module 50 generally includes a CPU or microprocessor 52, a memory device 54 accessible to the CPU 52, and a storage medium 56 that is also accessible to the CPU 52. The private key module 20 is executed on the CPU 52. The private key module 50 may be stored on the storage medium 56 or directly mounted on the memory device 52. The private key module 50 can store the private private key in its memory device 54 or its storage medium 56. As will be appreciated, the private key module 50 may have an input means for the user to enter a private private key, such as a keyboard when the private key module 50 is a smart card with a keyboard.

  Although a distinction has been made here between memory devices 54 that tend to be used to store more volatile data and storage media 56 that tend to be used to store more permanent data, Private key module 50 may have only a single data storage device for storing both volatile and persistent data. Similarly, user device 40 may have only a single data storage device for storing both volatile data and persistent data.

  Data link 60 provides a communication channel between application 10 and private key module 50 when needed. The data link 60 may be wired or wireless. It may be a direct connection between the user device 40 and the private key module 50. The data link 60 may be permanent, more preferably a connection established by request. In general, the data link 60 is not an open link but a protected link.

  As described above, the private key module 20 does not practice the entire KDF. The KDF component 24 generated in the private key module 50 implements only a reusable part and a part that performs basic cryptographic operations for security. Thereby, adaptability can be promoted without sacrificing safety. For example, when practicing the DH protocol, raw access to static DH private key operations is not allowed on the module. Instead, the module provides an interface that is sufficiently flexible to support all existing KDFs of interest, as well as all foreseeable KDFs. One way to do this most efficiently is to practice the intersection of existing and foreseeable KDFs. Most KDFs today are built on hash functions, although it is foreseen that some will be built from block ciphers in the future. Most private key modules should support at least a hash function, because the hash function is very important for the security of many algorithms, such as digital signatures. Fortunately, the number of standardized hash functions is less than KDF. For example, the hash function SHA-1 can be reused to support several different KDFs, such as separate ANSI, IPSec, and TLS key derivation functions. TLS key derivation also uses another hash function, MD5, which can be handled outside of module 50, as further described below.

  Referring to FIG. 3, for the KDF generated using the SHA-1 operation, the application 10 instructs the private key module 50 which input to supply as an input to the hash function. Some of the inputs are secret and are not known to the application. To specify this, the application 10 refers to such secret input via a handle or pointer 57. Public input may be provided directly by the application 10. The format of each KDF-specific input is specified by a general format interface provided by the module. The hash output that the private key module 50 provides to the application 10 can also be reused by the application 10 as a further input to more hash function calls. This is because many KDFs are based on a chaining mechanism in which the output of one hash call is fed to the input of another hash call.

  In one embodiment, private key module 50 includes SHA-1 practices and a simple interface. In an alternative embodiment, private key module 20 includes a general purpose execution environment.

  Or, the interface is implemented so that the module will allow both TLS PRF and ANSI X9.63 KDFs to be disclosed without unduly disclosing private key operations (the attacks discovered by the inventors of the present invention). Can be supported).

  In operation in support of ANSI X9.63 KDF and TLS PRF, ANSI X9.63 KDF calculates a series of hash values calculated based on the shared secret value from hash function SHA-1, and from the concatenation of hash values. The key is derived from the shared secret value by cutting the octet string that is formed, while the TLS PRF has a much more complex structure that includes the computation of both the hash function MD5 and the hash function SHA-1. ing.

  The purpose of the module interface 26 is not to practice the hash function MD5. Only the hash function SHA-1 is implemented on the private key module 20, that is, on the second part 24 of the KDF. Thus, the application 10 using the private key module 20 is responsible for practicing MD5 in its first part 22 of the KDF. From a safety point of view this is not a significant drawback. This is because MD5 hash functions are not universally considered to provide sufficient security, while SHA-1 hash functions have the highest security level (these higher levels are SHA). Tend to be universally accepted to provide sufficient security for the purpose of key derivation for all levels (except those requiring -256 or another SHA-1 successor protocol) Because.

  An overview of operations in support of ANSI X9.63 KDF is shown in FIG. In such an operation, application 10 selects X = 0 and Y = j‖ [SharedInfo], where j is a 4-octet counter maintained by the application. Application 10 then calls function 30 with the handles for X, Y and Z. The application 20 of the private key module 50 then calculates SHA-1 according to the equation described above and shown in FIG. 4 using the values for X and Y supplied by the application 10 and the handle for Z. The application 10 can then obtain the calculated SHA-1 value and use it to construct an ANSI X9.63 KDF and derive the key.

  The operation of applications 10 and 20 in support of TLS PRF is illustrated in FIG. The application 10 calls the first interface function 28 to halve the shared secret Z into S1 and S2 (part 1 in FIG. 5) as described above with respect to the function 28. The application 10 then calls the second interface function 30 to calculate a hash value based on S2 (part 2 of FIG. 5), and using this above configuration, the first and second interface functions 28, P_SHA-1 is calculated from 30 outputs (part 3 in FIG. 5). Parts 2 and 3 are described below.

  To construct the function HMAC-SHA-1 used in Part 2 of the TLS-PRF operation shown in FIG. 5, the application 10 first sets X = D and Y = M and handles with the key K. Two interface functions 30 are called, thereby giving T1 = SHA-1 ((D + K) ‖M) (the value of D is generally known to be constant and is therefore available to the application 10). Then, the application 10 sets X = C and Y = T with the same handle for K, and obtains T = SHA-1 (C + K) ‖T1) = HMAC-SHA (K, M) (the value of C is , D is public).

  If the key K needs to be padded with zero bits, the application 10 provides this by providing the second input Y with the necessary zero bits that are exclusive ORed with the appropriate octets of the constants C and D. Do. If the key K is long enough to initially require compression, the application 10 can do this by setting X = 0 and Y = 0 to obtain a hash key. In this case, since the application 10 has all the necessary information, it can optionally perform the rest of the computation on itself, or even use the third interface function to Can be designated as another secret for the new handle.

  To build the function P_SHA-1 in Part 3 of the operation supporting TLS-PRF shown in FIG. 3, the application 10 now uses S1 provided as output in Part 1 and the above configuration Then, HMAC_SHA-1 in which the secret key is confined in the private key module 20 is calculated. This involves calculating A (0), A (1), A (2) by repeatedly applying HMAC_SHA-1, which results in further applying P_SHA-1 by further applying HMAC_SHA-1. Form the output of

  The output P_SHA-1 is used to construct a KDF and derive a key.

  The above example assumes that the keys derived within the private key module 20 are derived as output to the application 10. In an alternative to this, the derived key remains in the private key module 20 and the output is just a handle or pointer to that key. An advantage of this is that all keys can be kept on the private key module 20, which further informs the module owner that the application cannot abuse the derived session key, let alone the long-term private key. Make sure.

  In an alternative embodiment, private key module 20 has a higher level of flexibility. Private key module 20 may support some simple execution language, such as javascript or java, thereby providing vast universality for operations performed on the card. That is, the application 10 supplies a program to the private key module 20 and the private key module 20 executes it. When the program is in a module, it can be freely accessed in secret. For security purposes, the private key module 20 ensures that all output from the module is an authorized security algorithm, such as a hash algorithm such as SHA-1 or part of a symmetric cryptographic operation such as AES. Make sure to go through. This prevents most abuses that a malicious program can try.

  To further increase security, the private key module 20 requires the program to digitally sign by a signer whose public verification key has already been securely loaded into the private key module 20. This is one way to authenticate programs loaded into the private key module 20. Program authentication ensures that the program is not a malicious execution program whose purpose is to endanger the secret of the module. Program authentication eliminates the need to limit module input to certain hashes, or other algorithms, because the program itself is reliable enough to execute any algorithm.

  The advantage of this alternative embodiment over the first embodiment is that it provides greater flexibility to allow a variety of existing or new hashes to be performed on the module. The disadvantage is that the module needs to support a general execution language and possibly a part of the public key infrastructure.

  Various embodiments of the invention have been described in detail. Those skilled in the art will appreciate that many modifications, adaptations, and variations may be made to the embodiments without departing from the scope of the present invention. Since changes in or in addition to the most preferred embodiments described above are possible without departing from the spirit, spirit and scope of the invention, the invention is not limited to those details and the appended claims Limited to only.

FIG. 1 is a block diagram illustrating a connection between a user device protected by a private key module and a connection destination. FIG. 2 is a schematic diagram showing the practice of the key derivation function in the user device and the private key module shown in FIG. FIG. 3 is a schematic diagram showing a private key module device. FIG. 4 is a flowchart showing one example of the key derivation function. FIG. 5 is a flowchart showing another example of the key derivation function.

Explanation of symbols

10 application 20 application 40 user device 50 private key module device 60 data link 70 link 80 public network 90 link 100 connection

Claims (20)

  A method of calculating an encryption operation on a computing device, the method comprising a secret value, wherein the secret value is stored on a module that communicates with the computing device via a data link, the method comprising:
  i) An application is executed on the computing device and refers to the secret value using a pointer to the secret value provided by the module, thereby causing the module to include at least the encryption operation including the secret value. Requesting to execute a subroutine;
  ii) the module executes the at least one subroutine using the secret value referenced by the pointer to obtain one or more cryptographic components;
  iii) the module providing the one or more cryptographic components to the application;
  iv) the application completing the encryption operation using the one or more cryptographic components;
  Including a method.   The method of claim 1, wherein the encryption operation is a key derivation function.   The method of claim 2, wherein the at least one subroutine executed by the module includes a hash function.   The key derivation function conforms to ANSI X9.63, the hash function includes a SHA-1 hash function, and the method includes:
  The application requests the module to execute the at least one subroutine by instructing the module to calculate the SHA-1 hash function for the secret value using the pointer. And
  The module performs the SHA-1 hash function on the secret value to generate a hash output;
  The module provides the hash output as the one or more cryptographic components;
  The application obtains the hash output as a further input, completes the encryption operation, and derives a key from the encryption operation;
  The method of claim 3, further comprising:   The method
  Requesting the module to execute the at least one subroutine by instructing the module to split a shared secret into a first half and a second half;
  The module providing, as a first output, a first half pointer corresponding to the first half and a second half pointer corresponding to the second half;
  The application references one pointer of the first half pointer and the second half pointer to one half of the first half and the second half. Instructing the module to execute the SHA-1 hash function;
  The module performs the SHA-1 hash function on the one half of the first half and the second half referenced by the application to result in the SHA-1 hash function And returning a result pointer of the SHA-1 hash function corresponding to the result of the SHA-1 hash function to the application.
  The method of claim 2 further comprising:   The application provides the module with a second set of inputs and a result pointer of the SHA-1 hash function, and is referenced by the second set of inputs and the result pointer of the SHA-1 hash function. Instructing the module to perform one or more iterations of the SHA-1 hash function based on the result of the SHA-1 hash function;
  The SHA-1 hash function referenced by the result pointer of the SHA-1 hash function in response to the instruction, the input of the second set, and the result pointer of the SHA-1 hash function. Performing the one or more iterations of the SHA-1 hash function using the result of, and returning the result of the one or more iterations of the SHA-1 hash function as a second output;
  The method of claim 5, further comprising:   The application further includes calculating P_SHA-1 using the first output and the second output, completing the key derivation function, and deriving a key from the key derivation function; The method of claim 5.   The result of the one or more iterations of the SHA-1 hash function includes a key, the second output includes a pointer to the key, and the method allows the application to subsequently include the pointer to the key. 6. The method of claim 5, further comprising instructing the module to perform an action using the key by reference.   An encryption device,
  The encryption device is:
  A device executing an application for calculating an encryption operation, wherein at least one subroutine of the encryption operation utilizes a secret value;
  A module that stores the secret value and includes a processor, wherein the processor executes the at least one subroutine to generate a cryptographic component using the secret value and to obtain a result from the cryptographic component Obviously, the module includes an interface that provides a first interface function and a second interface function, the first interface function allowing the secret value to be referenced. The second interface function directs the processor to execute the at least one subroutine using a secret referenced by the first interface function. When,
  A data connection between the first module and the application, which allows instructions from the application to the module and enables transfer of the results from the module to the application;
  And the application is further operable to complete the computation of the encryption operation using the result.   The apparatus of claim 9, wherein the module and the application are provided by a single device.   The apparatus of claim 9, wherein the module is protected by tamper-proof protection.   The module includes a program having a Java execution language provided by the application, and the program is for executing a subroutine from a plurality of encryption operations, and the module has a result of the subroutine as a result of the subroutine. The apparatus of claim 9, which ensures that it is processed using a secure algorithm before being output to.   13. The application of claim 12, wherein the application further includes a digital signature module for digitally signing the program, and the module further includes a public verification key for verifying a signature generated by the digital signature module. apparatus.   The apparatus of claim 9, wherein the encryption operation is a key derivation function and the at least one subroutine is a hash function.   The key derivation function conforms to ANSI X9.63 and the device
  The application executes the at least one subroutine to the module by instructing the module to calculate the hash function for the secret value using the first interface function. An application that works as required, and
  A module that executes the hash function on the secret value to generate a hash output; and
  Said module, said module providing said hash output as said one or more cryptographic components;
  An application that obtains the hash output as a further input to complete the encryption operation and derive a key from the encryption operation; and
  15. The apparatus of claim 14, further comprising:   The device is
  The application is operable to request the module to execute the at least one subroutine by instructing the module to split a shared secret into a first half and a second half With the application,
  The module, as the first interface function, provides a first half pointer corresponding to the first half and a second half pointer corresponding to the second half as a first output. A module that works to
  The application, wherein one half of the first half and the second half is referenced by referring to one of the first half pointer and the second half pointer An application that operates to instruct the module to perform a SHA-1 hash function on
  The SHA-1 hash function by executing the SHA-1 hash function on the one half of the first half and the second half referenced by the application; A module that operates to return a result pointer of the SHA-1 hash function corresponding to the result of the SHA-1 hash function to the application
  10. The apparatus of claim 9, further comprising:   The application provides a second set of inputs and a result pointer of the SHA-1 hash function to the module, and the second set of inputs and the result pointer of the SHA-1 hash function An application that operates to instruct the module to perform one or more iterations of the SHA-1 hash function based on the result of the referenced SHA-1 hash function;
  The SHA-1 which is the module and receives the indication, the input of the second set, and the result pointer of the SHA-1 hash function, and is referenced by the result pointer of the SHA-1 hash function Performing the one or more iterations of the SHA-1 hash function using the result of the hash function and returning the result of the one or more iterations of the SHA-1 hash function as a second output. Works like a module and
  The apparatus of claim 16, further comprising:   A method for calculating an encryption operation, the method comprising a secret value, the secret value being accessible to a module of the encryption device, the module executing on the encryption device via a data connection The module includes an interface that provides a first interface function and a second interface function, wherein the first interface function causes the secret value to be referenced by the application. Provides a pointer that can be prevented from being revealed, wherein the second interface function receives as an input value, and the pointer from the application utilizes a secret to at least one subroutine of the encryption operation On the module, the method comprising:
  Said application requesting said module to obtain a result from said at least one subroutine using said secret value, said secret value being said through said first interface function using said pointer. Being referenced by an application, and wherein the at least one subroutine is referenced through the second interface function;
  The application receiving the result from the module through the interface, wherein the result is executed by executing the at least one subroutine of the encryption operation utilizing the secret referenced by the pointer; Generated by the module; and
  The application using the result generated by the module to complete the computation of the encryption operation;
  Including a method.   The method of claim 18, wherein the encryption operation is a key derivation function.   The key derivation function includes a public key derivation function for generating a public key from a shared secret value, and the at least one subroutine includes a one-way function applied to the shared secret value. The method described.

Images