Authentication using public keys and session keys

One approach for authenticating data includes storing a plurality of combinations of representations of public keys and session key IDs in a non-volatile memory. A payload and accompanying public key, session key ID, and signature of the payload are input. The signature is a function of the payload and a private key of a key pair that includes the accompanying public key and the private key. Authenticity of the payload is determined based on the accompanying public key and session key ID and the combinations stored in the non-volatile memory, and from the signature and the payload. In response to determining that the payload is authentic, the payload is processed, and in response to determining that the payload is not authentic, processing of the payload is disabled.

FIELD OF THE INVENTION

The disclosure generally relates to authenticating data.

BACKGROUND

Authentication is generally a process by which a receiver of data determines whether or not the received data came from a trusted source. The data to be authenticated may be executable programs, configuration data for programmable logic, email messages, or application program data, for example.

One approach for authentication relies on public-private key pairs. Data is signed by the sender with the senders' private key of a key pair, resulting in a signature for that data. A receiver may use the sender's public key of the key pair and the received data to determine whether the signature sent with the data is that of the sender. If the signature is as expected for the received data, the received data is authenticated. Otherwise, the received data may have been sent from an unreliable source or may have been tampered with.

The public keys employed by a receiving device to authenticate input data are typically stored in a non-volatile memory of the device. Some implementations provide the capability to revoke a public key. Revoking a public key invalidates the key for subsequent use. In most cases a new public key may be established when a current public key is revoked.

Flash memory is often used to store public keys since it is non-volatile and can be reprogrammed. However, for some applications flash memory may be unsuitable. For example, field programmable gate arrays (FPGAs) are made using SRAM technology. Combining flash memory into an SRAM based device may be technically challenging and cost prohibitive. Therefore, e-fuses are sometimes used for storage of public keys. However, e-fuses occupy a large area relative to the small amount of information represented by the states of the e-fuses. Therefore, it would be desirable to have a cost-effective system for storage and revocation of public keys.

SUMMARY

A method of authenticating data is disclosed. The method includes storing a plurality of combinations of representations of public keys and session key identifiers (IDs) in a non-volatile memory. A payload and accompanying public key, session key ID, and signature of the payload are input. The signature is a function of the payload and a private key of a key pair that includes the accompanying public key and the private key. The method determines whether or not the payload is authentic, from the accompanying public key and session key ID and the combinations stored in the non-volatile memory, and from the signature and the payload. In response to determining that the payload is authentic, the payload is processed. In response to determining that the payload is not authentic, processing of the payload is disabled.

An authentication system is also described. The system includes non-volatile storage and a processor. The non-volatile storage is configurable for storage of a plurality of combinations of representations of public keys and session key IDs. The processor is coupled to the non-volatile storage and is configured to input a payload and accompanying public key, session key ID, and signature of the payload. The signature is a function of the payload and a private key of a key pair that includes the accompanying public key and the private key. The processor is further configured to determine whether or not the payload is authentic, from the accompanying public key and session key ID and the combinations stored in the non-volatile memory, and from the signature and the payload. Responsive to determining that the payload is authentic, the processor processes the payload. Responsive to determining that the payload is not authentic, the processor disables processing of the payload.

DETAILED DESCRIPTION OF THE DRAWINGS

The systems and methods provide an approach for securely managing authentication keys while also increasing the number of keys that may be used in the life of a device. The systems and methods use public keys, session key identifier (IDs), and a payload signature to authenticate a payload. Revocation of a public key or a session key associated with a session key ID is permitted only after the system has booted with configuration data or program code that has been authenticated. Revoking a key may also be referred to as invalidating a key.

In one implementation, the session key is a public key that can be used for authenticating software or hardware loads following the boot or initial configuration of the device. Another public key (or root key) and a session key ID, which are stored on the device, may be used in authenticating the initial boot program or hardware configuration and the accompanying session key. After the device has been configured or booted, subsequently loaded software or hardware configurations can be authenticated using the session key. This minimizes the use of the root key. As will be apparent from the disclosure below, the approach for revoking session key provides flexibility in managing the use of the session keys.

The system has non-volatile storage for multiple combinations of representations of public keys and session key IDs. The representations may be the binary format of the values of the actual public keys and session key IDs or may be binary formats of hash values of the public keys and session key IDs. For ease of explanation, public key and session key ID may be used when referring to the representations thereof.

A payload input to the system is accompanied by a public key, a session key ID, and a signature of the payload. The signature is a function of the payload and a private key of a key pair that includes the accompanying public key and the private key. The system includes a processor which determines whether or not the payload is authentic. The authenticity of the payload is determined based not only on the signature of the payload, but also on the accompanying public key and session key ID and the combinations of representations of public and session key IDs stored in the non-volatile memory.

If the payload is authentic, the processor allows the payload to be processed. If the payload is not authentic, the processor disables further processing of the payload. In an example application, the processing of the payload may entail booting the system with program code contained in the payload or configuring programmable logic such as may be found in a system-on-a-chip (SOC).

FIG. 1is a flow diagram that shows the construction of authentication information for a payload, and the authentication of the payload for purposes of enabling revocation of authentication keys. In an example application, the payload may be a boot program for a processor or configuration data for programmable logic, for example. The flow diagram shows two general phases, the construction of the authentication information and the authentication of the payload using the authentication information. The construction of the authentication information is marked with brace102, and the authentication is marked with brace104.

The payload106to be provided to a system has an accompanying public key Pu108and session key ID110. The payload may include the session key corresponding to session key ID110. The payload is input to a hash function112, which computes a hash value114based on the payload. In an alternative implementation, both the public key108and the session key ID110may be input to the hash function. In an example implementation the hash function may be an SHA-based function. The hash value114is encrypted with the private key Pr116by encryption function118, resulting in signature120. The signature120is appended to the information that accompanies the payload106. The payload106, public key108, session key ID110, and signature120may be formatted into a configuration file to be used in a secure boot of a system in an example application.

The authentication of the payload is performed by the system that inputs the payload106and accompanying public key108, session key ID110, and signature120. The system includes a non-volatile memory132for storage of representations of the public keys134and session key IDs136. In one implementation, hash values of the public keys are stored in order to reduce storage requirements. For example, the result produced from a hash function applied to a 2048-bit public key may be 256 bits. In another implementation, the public keys are not hashed. The non-volatile memory also includes storage for key states of the public keys. The key state for each public key may be indicated by a valid bit138that is associated with that public key. The public keys134, session key IDs136, and valid bits138may be stored in e-fuses, for example.

In an implementation in which the non-volatile memory stores hash values of public keys, the public key108that accompanies the input payload106is input to a hash function140to produce hash value142. Compare function144compares the hash value142to the hash values of the public keys134in the non-volatile memory. In response to the hash value142not matching any of the hashed public keys134, the compare function designates the payload to be not authentic, and the system disables further processing of the payload106with lock-down function146. For example, the processor may lockdown the system by aborting booting of the system or aborting configuring programmable logic. The designation may be by way of the state of a signal or value stored in a register or memory.

In another implementation, each combination of one of session key IDs136and public keys134may be a single hash value. In this implementation, both the public key108and session key ID110that accompany the payload106are input to the hash function140, and the compare function144compares the resulting hash value to the combined value of a hashed public key and session key ID in the non-volatile memory.

If the compare function144finds a match, the valid function148determines whether or not the valid bit associated with the matching hashed public key (or alternatively, matching combination of hashed public key and session key ID, or matching non-hashed public key), has a key state that indicates that the key(s) is valid. If the key state indicates that the matching key is not valid, the valid function148designates the payload to be not authentic, and the system disables further processing of the payload106with lock-down function150, such as by aborting booting of the system or aborting configuring programmable logic.

In response to the valid bit having a key state that indicates that the key(s) is valid, the signature of the payload106is confirmed by inputting the payload106to hash function152, which would be the same as hash function112, and generating hash value154. The signature120and public key108that accompany the payload106are input to decryption function156, which decrypts the signature using the public key, resulting in decrypted signature158. The compare function160compares the computed hash value to the decrypted signature. In response to the signature failing to match, the system disables further processing of the payload106with lock-down function162, such as by aborting booting of the system or aborting configuring programmable logic.

In response to the decrypted signature matching the hash value, the compare function164compares the session key ID110that accompanies the input payload to the session key ID in the non-volatile memory132that is associated with the matching one of the hashed public keys134. In response to the session key ID120not matching the one of the session key IDs136, the compare function164designates the payload to be not authentic, and the system disables further processing of the payload106with lock-down function166, such as by aborting booting of the system or aborting configuring programmable logic. In response to the session key ID120matching the one of the session key IDs136, the system enables processing of the payload106, such as by continuing with execution of a boot program and/or configuration of programmable logic168. In the implementation in which each combination of one of session key IDs136and one of public keys134is a single hash value, the compare function164is not required, and a positive comparison found by compare function160continues with processing function168, such as execution of a boot program and/or configuration of programmable logic168.

A session key may be revoked independent of the associated public key. In an example implementation, each of session key IDs136is stored in a set of e-fuses. To revoke a session key, current flow is disabled through the one of the e-fuses of the session key ID. The blown fuse changes the value of the session key ID, which effectively revokes the previous session key ID stored in the set of fuses. In an example implementation, the session key IDs are thereby stored in unary format.

Revoking a public key revokes not only the public key but also effectively revokes the associated session key. As explained above, the non-volatile memory132includes valid bits for storage of key states that are associated with the combinations of public keys134and session key IDs136. Each combination includes a one of the public keys and one of the session key IDs. The key state in the valid bit associated with a combination indicates whether or not the associated combination is valid (has not been revoked). The valid bits may be implemented as e-fuses.

FIG. 2is a block diagram that shows a system200in which authentication keys are used to control the booting and/or configuration of the system. The system200includes a processor202, programmable logic204, ROM206, RAM208, non-volatile memory132, ROM212, storage214, and interfaces216,218, and220. The processor202, programmable logic204, ROM206, RAM208, non-volatile memory132, and interfaces216,218, and220may be implemented as a system-on-a-chip (SOC). A combination of one of the public keys134and one of the session key IDs136is used by the processor to authenticate the first stage boot loader (FSBL)232and/or configuration bitstream234. Once authenticated, the processor in executing FSBL code or the programmable logic as configured with the configuration bitstream, is enabled to revoke one of the public keys and/or session key IDs.

In booting the system, the processor202loads and executes program code from ROM206. That code causes the processor to input the FSBL232and/or configuration bitstream234into RAM208and then authenticate the FSBL or bitstream. The FSBL and configuration bitstream input to the processor have an accompanying public key, session key ID, and signature. If the processor determines the input FSBL or bitstream to be authentic as described above, the processor may continue by processing the payload, that is by executing program code of the FSBL or configuring the programmable logic204with the configuration bitstream.

The non-volatile memory132is comprised of e-fuses in an example implementation. A public key is established by blowing selected e-fuses to establish a binary value of the public key or a hash of the public key. The session key ID associated with a public key is also established by blowing one or more e-fuses to represent the value of the session key ID. A new session key may be established for use in combination with the associated public key by blowing another e-fuse of the e-fuses for that session key ID. The session key ID is thereby embodied in a unary format in the e-fuses. For example, if 32 e-fuses are used to represent a session key ID, then the session key ID can have 32 different values.

The valid bits138associated with the combinations of public keys and session key IDs are also implemented with e-fuses. When the e-fuse of a valid bit is blown, the public key is invalidated, and because the session key ID associated with the public key is only used with that public key, the session key associated with that session key ID is also effectively invalidated. The e-fuses of the valid bits138and session key IDs136may be blown by program code executing on the processor202or by circuitry configured in the programmable logic204only after the program code or configuration bitstream has been authenticated.

In one implementation, a write-enable (WE) e-fuse242controls all but the first public key. This allows the processor running unauthenticated program code or programmable logic configured with an unauthenticated configuration bitstream to program the first public key. The very first programming of the public key space is allowed to be done without authentication because there is no key in the non-volatile memory132with which to authenticate. After the first public key has been configured, subsequent programming or revocation of keys is permitted only after the program code or configuration bitstream has been authenticated.

The public keys other than the first public key may be controlled by the WE e-fuse242. The e-fuse of the WE bit can be blown once all desired values of the public keys are programmed. In another implementation, individual WE bits may be used to individually control programming of the public keys.

The system protects against unauthorized programming of the public keys. An authorized party, at the initial programming of the public keys, may configure values for all the public keys134in the e-fuses. The WE e-fuse242can then be blown to disable any further configuration of the public keys. In an alternative approach, the authorized party, at the initial programming may configure the value for only the public key that is not protected by the WE e-fuse (the first public key). Thereafter, before any other public key can be configured or revoked, any input program code or configuration bitstream must first be authenticated with a valid public key and session key.

FIG. 3is a flowchart of a process for initially configuring the authentication system. At block302, the representations of one or more public keys are configured in the non-volatile memory. The representation of each public key may be the actual value of the public key or a hash value of the public key, depending on implementation requirements.

In one implementation, all the public keys are configured in the non-volatile memory at the initial setup. Alternatively, only the first public key is configured, and thereafter, conditioned on authentication of program code or a configuration bitstream, other public keys can be configured by a program running on a processor of the SOC or by a circuit configured in the programmable logic of the SOC.

At block304, the values or one or more session key IDs may be optionally configured in the non-volatile memory. An initial session key ID may be configured for each public key which was configured at block302. The configuration of session key IDs is optional because the initial value for a session key ID may be 0, which would not require the blowing of any e-fuses. However, if a value other than 0 is desired, the e-fuses may be blown to indicate that value.

The WE e-fuse that controls the public keys optionally may be blown at block306. This may be useful in usage scenarios in which all the public keys are configured in the SOC at initial setup. Blowing the WE e-fuse disables subsequent updating of the public keys.

FIG. 4is a flowchart of a process of authenticating an input payload using a public key and a session key ID. At block402, the process reads the input public key that accompanies a payload and at block404a hash value is computed from the public key. In implementations in which the actual public key is stored in non-volatile memory, no hash value would need to be computed.

If the computed hash value does not match any of the hashed public keys stored in the non-volatile memory, decision block406directs the process to block408where the system is locked down. For example, a processor performing the authentication may abort further booting of the system or abort configuration of programmable logic.

If the computed hash value does not match any of the hashed public keys stored in the non-volatile memory, decision block406directs the process to decision block410, which checks whether or not the matching hashed public key is valid from the state of the associated valid bit. If the hashed public key is not valid, the system is locked down at block408.

If the hashed public key is valid, at block412, a hash value is computed from the payload, and at block414, the signature that accompanies the payload is read and decrypted using the input public key.

At block416, the session key ID is read from the input, and decision block418determines whether or not the input session key ID matches the session key ID associated with the matching public key in the non-volatile memory. If the input session key ID does not match, the system is locked down at block408. Otherwise, decision block420determines whether or not the decrypted signature is equal to the hash value computed from the payload at block412. If the decrypted signature does not match, the system is locked down at block422. Otherwise, the processor may continue with program execution or configuration of programmable logic at block424.

In an implementation in which the public key and session key ID are hashed together (not shown), a single hash value would be computed from the input public key and session key ID and that hash value would be compared to the hash values of public keys and session key IDs stored in non-volatile memory. Thus, blocks402,404, and406could be modified to process the input session key ID in combination with the input public key, and blocks416and418would not be necessary.

FIG. 5is a flowchart of a process of revoking a public key or a session key. In an SOC implementation, revocation of either a public key or session key can only be performed by authenticated program code executing on a processor of the SOC or by programmable logic of the SOC as configured with an authenticated configuration bitstream.

At block502, an input payload is authenticated. The payload may be either program code or a configuration bitstream, for example, and may include a session key. The authentication uses a signature of the payload, along with a public key and a session key ID that also accompany the payload.

At block504, to revoke a public key, the e-fuse that implements a valid bit associated with the public key is blown. Since each session key is used only with one of the possible public keys, revoking the public key effectively revokes the combination of the public key and the associated session key.

To revoke a session key, at block506, one or more of the set of e-fuses that implements the session key ID associated with the revoked session key are blown. Since blowing an e-fuse changes the value of the session key ID, the previous session key ID stored by the set of e-fuses is revoked, and the new session key ID is indicated by the state of the set of e-fuses. It will be appreciated that blowing only one e-fuse to revoke a session key ID maximizes the number of session key IDs that can be used with that set of e-fuses since once an e-fuse is blown it cannot thereafter be reconfigured to conduct current.

FIG. 6is an example SOC architecture600on which a system may be implemented using the various approaches described herein. Those skilled in the art will appreciate that the SOC ofFIG. 6provides only one example of an integrated circuit device on which the methods of the present invention can be practiced. SOC600includes a large number of different programmable tiles including multi-gigabit transceivers (MGTs601), configurable logic blocks (CLBs602), random access memory blocks (BRAMs603), input/output blocks (IOBs604), configuration and clocking logic (CONFIG/CLOCKS605), digital signal processing blocks (DSPs606), specialized input/output blocks (I/O607) (e.g., configuration ports and clock ports), and other programmable logic608such as digital clock managers, analog-to-digital converters, system monitoring logic, and so forth. The example SOC also includes a hardwired processor610.

In some implementations, each programmable tile includes a programmable interconnect element (INT611) having standardized connections to and from a corresponding interconnect element in each adjacent tile. Therefore, the programmable interconnect elements taken together implement the programmable interconnect resources for the illustrated SOC. The programmable interconnect element (INT611) also includes the connections to and from the programmable logic primitive within the same tile, as shown by the examples included at the top ofFIG. 6.

For example, a CLB602can include a configurable logic primitive (CLE612) that can be programmed to implement user logic plus a single programmable interconnect element (INT611). A BRAM603can include a BRAM logic primitive (BRL613) in addition to one or more programmable interconnect elements. Typically, the number of interconnect elements included in a tile depends on the height of the tile. In the pictured embodiment, a BRAM tile has the same height as four CLBs, but other numbers (e.g., five) can also be used. A DSP tile606can include a DSP logic primitive (DSPL614) in addition to an appropriate number of programmable interconnect elements. An10B604can include, for example, two instances of an input/output logic primitive (IOL615) in addition to one instance of the programmable interconnect element (INT611). As will be clear to those of skill in the art, the actual I/O pads connected, for example, to the I/O logic primitive615are manufactured using metal layered above the various illustrated logic blocks, and typically are not confined to the area of the input/output logic primitive615.

Some SOCs utilizing the architecture illustrated inFIG. 6include additional logic blocks that disrupt the regular columnar structure making up a large part of the programmable logic. The additional logic blocks can be programmable blocks and/or dedicated logic. For example, the processor block PROC610shown inFIG. 6spans several columns of CLBs and BRAMs.

In the pictured embodiment, a columnar area near the center of the die (shown shaded inFIG. 6) is used for configuration, clock, and other control logic. Horizontal areas609extending from this column are used to distribute the clocks and configuration signals across the breadth of the SOC. A configuration port (not shown) may be used to access configuration memory (not shown) for the programmable logic to configure the programmable logic and interconnect resources. In one embodiment, an internal scrubber (not shown) may continuously read and correct configuration memory via an internal configuration access port.

Though aspects and features may in some cases be described in individual figures, it will be appreciated that features from one figure can be combined with features of another figure even though the combination is not explicitly shown or explicitly described as a combination.

The system and methods are thought to be applicable to a variety of systems for authentication. Other aspects and features will be apparent to those skilled in the art from consideration of the specification. The systems and methods may be implemented as one or more processors configured to execute software, as an application specific integrated circuit (ASIC), or as a logic on a programmable logic device. It is intended that the specification and drawings be considered as examples only, with a true scope of the invention being indicated by the following claims.