 |
Electronic Components Datasheet Search |
|
|
Electronic Components Datasheet Search |
|
ADSP-2141LKS-E1 Datasheet(PDF) 6 Page - Analog Devices |
|
||||||||||||||||||||||||||||||
ADSP-2141LKS-E1 Datasheet(HTML) 6 Page - Analog Devices |
|
|
6 / 39 page  REV. 0 ADSP-2141L –6– Context switching is optimized to minimize the overhead of changing cryptographic keys to near zero. The software interface to the module consists of a set of memory-mapped registers, all of which are visible to the DSP and most of which can be enabled for host access via the PCI bus. A set of five, 16-bit registers define the operation to be performed, the length of the data buffer to be processed, in bytes, the offset between the start of hashing and encryption (or vice versa), and the padding operation. If the data length is unknown at the time the encrypt/decrypt operation is started, the data length register may be set to zero, which specifies special handling. In this case, data may be passed to the hash/encrypt block indefinitely until the end of data is encountered. At that time, the operation is terminated by writing a new control word to the hash/encrypt control register (either to process the next packet or to invoke the idle state if there is no further work to do). This will close out the processing for the packet, including the addition of the selected crypto padding. A set of seven status registers provides information on when a new operation can be started, when there is space available to accept new data, when there is data available to be read out, and the results from the padding operation. Crypto Contexts There are two sets of crypto-context registers. Each context contains a DES or triple DES key, initialization vector, and precomputed hashes (inner and outer) of the authentication key for HMAC operations. The contexts also contain registers to reload the byte count from a previous operation (which is part of the hashing context), as well as an IV (also called salt) for decrypting a black key, if necessary. Once a crypto-context has been loaded and the operation defined, data is processed by writing it to a data input FIFO. At the I/O interface, data is always written to, or read from, the same address. Internally, the hash and encryption functions have separate 512-bit FIFOs, each with their own FIFO man- agement pointers. Incoming data is automatically routed to one or both of these FIFOs, depending on the operation in progress. Output from the encryption block is read from the data output FIFO. In encrypt-hash or decrypt-hash operations, the data is also automatically passed to the hashing data input FIFO. Output from the hash function is always read from the digest register of the appropriate crypto-context. The initialization vector to be used for a crypto operation can be loaded as part of a crypto-context. When an operation is complete, the same context will contain the resulting IV produced at the end, which can be saved away and restored later to continue the operation with more data. In certain packet-based applications such as IPsec, a feature is available that avoids the need for the control software to generate and load random IVs for outgoing (encrypted) packets. Effec- tively, the IV register can be configured to be automatically updated with new random numbers for each encrypted packet, with almost no software intervention. Padding When the input data is not a multiple of eight bytes (a 64-bit DES block), the encrypt module can be configured to automati- cally append pad bytes. There are several options for how the padding is constructed, which are specified using the pad control word of the operation description. Options include zero padding, pad-length character padding (PKCS#7), incrementing count, with trailing pad length and next header byte (for IPsec), or fixed character padding. Note that for the IPsec and PKCS#7 pad protocols, there are cases where the padding not only fills out the last 8-byte block, but also causes an additional 8-byte block of padding to be added. For the hash operations, padding is automatically added as specified in the MD-5 and SHA-1 standards. When the hash final command is issued indicating the last of the input data, the algorithm-specified padding and data count bits are added to the end of the hash input buffer prior to computing the hash. Data Offsets Certain security protocols, including IPsec, require portions of a data packet to be hashed while the remainder of the data is both hashed and encrypted. The ADSP-2141L supports this require- ment through the OFFSET register, which allows specifying the number of 32-bit dwords of offset between the hash and encrypt/ decrypt operations. Black Key Loads The cryptographic keys loaded as part of a crypto-context can be stored off-chip in a black, or encrypted, form. If the appropri- ate control bit is set (HECNTL Bit 15), the DES or 3-DES key will be decrypted immediately after it is written into the context register. The hardware handles this decryption automatically. The Key Encryption Key (KEK) that covers the black keys is loaded in a dedicated write-only KEK register within the ADSP-2141L. The IV for decrypting the black secret key is called ‘salt’ and must be stored along with the black key (as part of the context). Note that 3-DES CBC mode is used for pro- tecting 3-DES black keys and single DES CBC is used for single DES black keys. When black keys are used, the key-decrypt operation adds a 6-cycle overhead (0.15 µs @ 40 MHz) for DES keys or 36-cycle overhead (0.9 µs @ 40 MHz) for triple DES keys each time a new crypto-context is loaded. (Note that if the same context is used for more than one packet operation, the key decryption does not need to be performed again.) Depending on the sequencing of operations, this key decryption may in fact be hidden (from a performance impact perspective) if other operations are underway. This is because the black key decryption process only requires that the DES hardware be available. For example, if the DSP is reading the previous hash result from the output FIFO, the black key decryption can be going on in parallel. Also note that the data driver firmware does NOT have to wait for the key to be decrypted before writing data to the input FIFO. The hard- ware automatically waits for the key to be decrypted before beginning to process data for a given packet. So, with efficient pipeline programming, it is possible to make the impact of black key essentially zero. The KEK for key decryption is loaded via the secure kernel firmware using one of the CGX key manipulation commands. (For more information, see the Command Summary section.) This KEK is typically the same for all black keys, since it is usually protecting local storage only. It is designated the DKEK in the CGX API. One of the laser-programmed configuration bits specifies whether red (plaintext) keys are allowed to be loaded into the ADSP- 2141L from a host. If the AllowRedKeyLoad laser bit is not set, keys may only be loaded in their black form. This is useful in systems where export restrictions limit the key length that may be used or where the external storage environment is untrusted. |
Similar Part No. - ADSP-2141LKS-E1 |
|
Similar Description - ADSP-2141LKS-E1 |
|
|
Link URL |
| Privacy Policy |
| ALLDATASHEET.NET |
| Does ALLDATASHEET help your business so far? [ DONATE ] |
About Alldatasheet | Advertisement | Contact us | Privacy Policy | Link Exchange | Manufacturer List All Rights Reserved©Alldatasheet.com |
| Russian : Alldatasheetru.com | Korean : Alldatasheet.co.kr | Spanish : Alldatasheet.es | French : Alldatasheet.fr | Italian : Alldatasheetit.com Portuguese : Alldatasheetpt.com | Polish : Alldatasheet.pl | Vietnamese : Alldatasheet.vn Indian : Alldatasheet.in | Mexican : Alldatasheet.com.mx | British : Alldatasheet.co.uk | New Zealand : Alldatasheet.co.nz |
|
Family Site : ic2ic.com |
icmetro.com |
English ▼
English
Chinese
German
Japanese
Russian
Korean
Spanish
French
Italian
Portuguese
Polish
Vietnamese
Indian
Mexican
British
New Zealand
