Patent Application
20140258729
This disclosure relates generally to cryptographic processing devices.
Computer systems (e.g., personal computers, smart phones, electronic tablets) have communication ports that are used to couple to peripheral devices (e.g., printers, headphones, charging cables). In some applications, it is desirable to authenticate peripheral devices to ensure compatibility or to protect sensitive information. Authentication can be performed using a Digital Signal Algorithm (DSA), such as Elliptic Curve DSA (ECDSA).
A DSA may be implemented in a hardware authentication device. The hardware authentication device may be an integrated circuit chip that is embedded in a computer system. The authentication device may be configured to perform various high security applications, such as anti-counterfeiting, protection for firmware or media, session key exchange, secure data storage and user password checking A DSA often performs multiple asymmetric cryptographic operations using secure data (e.g., a private key).
Key authorization is a standard cryptographic requirement in many systems and can be used to prevent fraudulent use of a key if the device containing the key is stolen or otherwise available. For instance, if a key is used as identification for a person the authorizing value could be a password known only to the person. If the device with the ID is stolen, the thief cannot use the device to sign fraudulent messages since he does not know the password. Conventional authentication devices fail to retain key authentication status in a secure manner, resulting in reduced authentication speed in sessions where subsequent cryptographic operations using the same key are performed.
A hardware authentication device is disclosed that uses a cryptographic signature verification operation to authorize a subsequent cryptographic operation to be performed using the same or different keys and stores that authorization status in protected memory. The cryptographic algorithm may be an ECDSA signature, SHA-based Message Authentication Code (MAC) or any other cryptographic algorithm. The authorization status may be stored for a number of uses for a period of time or until a certain event occurs. In some implementations, the authorization status and the key that was authorized are stored in the same protected location in memory to preserve their relation to each other and prevent modification of either of them. Depending on system policy, the authorization mechanism might be a static stored token that authorizes key use or an authorization process that is regenerated using a random (e.g., unique) number.
Particular implementations disclosed herein provide one or more of the following advantages: 1) storing authorization status provides hardware authentication devices with a low cost, easily integrated method to improve system confidence and increase the total value of the solution, and enables host devices that require authentication to better achieve a desired throughput in real time; 2) storing authorization status helps increase peripheral devices (e.g., printers, smartphone accessories) to authenticate quickly; and 3) the authorization status and the corresponding key are stored together in secure memory to preserve their relation to each other and prevent modification of either of them, thus giving the authorizing entity confidence in the way that authorization has been used and providing the user with a convenient or practical way to get the protected feature or function.
Controller 104 can execute commands received on interface 102 and perform cryptographic algorithms in response to the commands, including but not limited to hash algorithms (e.g., SHA-256) and public key encryption algorithms (e.g., ECDSA). Some examples of applications for authentication device 100 include but are not limited to anti-clone for accessories, daughter cards and consumables, secure boot validation, software anti-piracy, network and computer access control, password handling, and authenticated/encrypted network communications
Memory 106 can be used to store keys (e.g., public and private keys), miscellaneous read/write, read-only or secret data, consumption logging and security configuration. Access to various sections of memory 106 can be restricted in a variety of ways and then the configuration locked to prevent changes. In some implementations, memory 106 may have slot 108 including a number of bytes of memory 106. A first portion 110 of slot 108 may include one or more bits for storing a flag and a second portion 112 of slot 108 may include one or more bytes for storing a key associated with the flag (e.g., a public key). The key may be stored at any desired location on device 100 or generated on-the-fly from a private key if also stored on device 100. The flag and the key may be stored in device 100 as a secure package to preserve their relation to each other and to protect both the flag and the key from attacks.
In some implementations, the flag indicates an authorization state for the key. Slot 108 may be set in response to one or more internal commands or commands received over interface 102 during an authentication session. The flag may be a single bit that indicates an authorization state for the key. For example, if the flag is set (e.g., set to 1), then the authorization state for the key is valid and the key may be used in a cryptographic operation without reauthorizing the key. By avoiding reauthorizing the key for each cryptographic operation using the key (e.g., repeating cryptographic operations on the same key), the authentication session may be completed more quickly. In some implementations, the key may be a public key, and the authorization sequence may include verifying that the signature is correctly generated from a given message and the public key using an ECDSA signature verification algorithm (e.g., FIPS 186-3). The public key may be stored in memory 106 or other secure memory, such as portion 112 of slot 108 of memory 106.
In some implementations, the flag and key may be stored in a hardware register in device 100 in response to a command received over interface 102. This allows the flag and key to be read by the host system. For example, a flag and key may be stored in hardware register 114 in controller 104, where it may be read out by a host system through interface 102. In some implementations, register 114 may be cleared at the time a new authorization is being performed with the same or different key. In another or the same implementation, register 114 may be cleared each time register 114 is read. Clearing register 114 each time register 114 is read enables a single use strategy for improved security.
In some implementations, writing to register 114 resets a counter. Each time register 114 is read the counter is incremented or decremented (e.g., incremented or decremented by 1). The flag would indicate that the authorization sequence is invalid if the counter reaches a certain predetermined value. In another or the same implementation, writing to register 114 resets a timer. Each time register 114 is read the timer starts. The flag would indicate that the authorization sequence is invalid if a timer value expires. The timer and counter may be implemented in software by controller 102 and/or implemented in hardware.
Example Key Authorization Process
In some implementations, process 200 may begin by obtaining a request to authorize a key (202). The request may be in the form of a command received from a host system over a bus or from an internally generated command.
Process 200 may continue by obtaining an authenticating token (204). The token may be an n-bit number stored in secure memory (e.g., 128 or 256 bits). An example token may be a digest of a password. The token may be in obtained from a removable storage device that a user may retrieve when the user needs to use a key (e.g., a public key) that requires authentication. The token may be stored in non-volatile memory (e.g., Flash, hard disk) within an authentication device, which has authority to use the key, or could be transmitted to an authentication device by a third party at the time in which authorization is required and therefore not stored by the authentication device at all.
Process 200 may continue by determining that the key is authorized based on the token (206), and setting an authorization status flag (208). The flag may be stored in memory or in a hardware register for multiple uses or later use at the same or different location. If a cryptographic operation needs to use the key, the flag may be read to determine if the key is authorized. If the key is authorized as indicated by the flag value, the cryptographic operation may be performed using the authorized key without reauthorizing the key.
Process 200 may continue by performing one or more cryptographic operations using the authorized key (210). A cryptographic operation may be any operation that a cryptographic algorithm would perform using an authorized key (e.g., ECDSA operation).
In some implementations, process 300 may begin by obtaining a request to use a key (302). Process 300 may continue by obtaining an authorization status flag to determine if the key is authorized (304). The status flag may be read from memory or a hardware register.
Process 300 may continue by determining that the key is valid based on the status flag (306). The key may be an n-bit integer (e.g., 1-bit), which if set (e.g., set to 1) indicates that the key is authorized.
Process 300 may continue by performing one or more cryptographic operations using the authorized key (308). If the status flag indicates that the key is not authorized, the key may be reauthorized depending on system policy. Depending on system policy, the authorization mechanism might be a static stored token that authorizes key use or an authorization process that is regenerated using a random (e.g., unique) number.
In some implementations, device 100 implements hierarchy or chaining that has two or more levels. For example, a status flag may be stored for a parent key of a second or child key. When an authentication token is presented to the authentication device 100, the authorized parent key may be used to compute a function to set (or not, depending on the computation result) a status flag for the second or child key.
While this document contains many specific implementation details, these should not be construed as limitations on the scope what may be claimed, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can, in some cases, be excised from the combination, and the claimed combination may be directed to a sub combination or variation of a sub combination.
