Abstract:
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 external token that authorizes key use or an authorization process that is regenerated using a random (e.g., unique) number.

Description:
TECHNICAL FIELD 
       [0001]    This disclosure relates generally to cryptographic processing devices. 
       BACKGROUND 
       [0002]    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). 
         [0003]    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). 
         [0004]    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. 
       SUMMARY 
       [0005]    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. 
         [0006]    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. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]      FIG. 1  illustrates an example authentication device for storing key authorization status. 
           [0008]      FIG. 2  is a flow diagram illustrating an example process for setting key authorization status. 
           [0009]      FIG. 3  is a flow diagram illustrating an example process for obtaining key authorization status. 
       
    
    
     DETAILED DESCRIPTION 
     Example Hardware Authentication Device 
       [0010]      FIG. 1  illustrates an example hardware authentication device  100  for storing key authorization status. Device  100  may be an integrated circuit (IC) chip. Device  100  may be included in a data processing device, such as a personal computer, smartphone, electronic tablet or any other device that requires or performs authentication. In the configuration shown, device  100  includes interface  102 , controller  104  and memory  106 . Interface  102  may be a standard two-wire interface (e.g., a I 2 C interface) or single wire interface for communication with host systems. Controller  104  may be a microcontroller or any kind of sequencer based on logic (e.g., digital logic). Memory  106  may be Electrically Erasable Programmable Read-Only Memory (EEPROM) or any other suitable memory (e.g., SRAM). 
         [0011]    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 
         [0012]    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. 
         [0013]    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 . 
         [0014]    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. 
         [0015]    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. 
         [0016]    Example Key Authorization Process 
         [0017]      FIG. 2  is a flow diagram illustrating an example process  200  for setting key authorization status. Process  200  may be implemented by controller  102  in authentication device  100 , as described in reference to  FIG. 1 . 
         [0018]    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. 
         [0019]    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. 
         [0020]    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. 
         [0021]    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). 
         [0022]      FIG. 3  is a flow diagram illustrating an example process  300  for obtaining key authorization status. Process  300  may be implemented by controller  102  in authentication device  100 , as described in reference to  FIG. 1 . 
         [0023]    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. 
         [0024]    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. 
         [0025]    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. 
         [0026]    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. 
         [0027]    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.