MPC8536E-ANDROID Freescale Semiconductor, MPC8536E-ANDROID Datasheet - Page 508

• Manufacturer Part Number: MPC8536E-ANDROID
• Description: HARDWARE/SOFTWARE ANDROID OS
• Manufacturer: Freescale Semiconductor
• Series: PowerQUICC ™r
• Type: MPUr

Specifications of MPC8536E-ANDROID

• Contents: Board
• For Use With/related Products: MPC8536
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant

Security Engine (SEC) 3.0
Options and Operation for GCM Cipher Mode
Galois counter mode (GCM) uses AES counter mode to achieve data confidentiality. Authentication is
achieved by computing a GHASH message authentication code (GMAC) through performing repetitive
multiplication-accumulate functions in a Galois field.
Normally, the initialization vector (which is provided through the input FIFO) is 96 bits. If it is 96 bits,
then the initialization vector (IV) is padded with the value ({0}
GHASH (H, {}, IV) function, where H represents E({0}
represents the key used. The resulting value Y
initial counter value to counter mode AES. The result of encrypting Y
to generate the final MAC tag.
Data is encrypted or decrypted by XORing input data with the pseudorandom key stream generated by
counter mode AES, starting with the second pseudorandom key block. The initial counter value Y
incremented modulo 2
GCM cipher mode can optionally be used to perform only the authentication part (GHASH (H, AAD,
ciphertext), where ‘AAD’ denotes ‘additional authenticated data’): this special sub-mode is called
GCM-GHASH in this document. GCM-GHASH is implemented by setting AUX0 and specifying the
appropriate encryption operation. The format of the context registers for GCM-GHASH mode is shown in
Table
GCM cipher mode also has option of automatically verifying that the received and computed MAC tags
are identical. This cipher mode is called GCM with ICV and can be specified by setting AESU mode
register bits 56, 57 and 62 to 1, and bit 61 to 0. GCM with ICV context format is shown in
Messages (IV+AAD+text data) are fed in through the input FIFO, and are always processed in the
following order: IV, AAD, text data, followed by the final MAC computation (where “text data” refers to
plaintext or ciphertext to be operated on). The whole message, however, does not have to be processed in
one GCM execution. It can be split and processed with multiple descriptors in multiple GCM runs
separated by resets of the AESU block. The boundaries can be set at the end of any full block (16 bytes)
of the stream IV+AAD+text data. Hence, any of the individual components (IV, AAD, or text data) can be
split into multiple descriptors. Refer to
Table 10-33
decrypt, GCM with ICV, or GCM-GHASH). It should be noted that in case of a late arrival of the MAC
tag on the receiving side, the final MAC can be computed and verified against the received MAC in a
separate descriptor after the rest of the message (IV+AAD+text data) has already been processed.
10-78
1.Notation: {0}
10-36.
through
For both encrypt and decrypt operations, if the 802.11 frame is being
processed as a whole (not split across multiple descriptors), the “Initialize”
(AUX1) and “Final MAC” (AUX2) bits should be set in the AESU mode
register.
31
1 is defined to mean a string of thirty-one bits of 0 followed by a single bit of 1.
MPC8536E PowerQUICC III Integrated Processor Reference Manual, Rev. 1
Table 10-36
32
.
for proper context formatting under the different GCM options (encrypt,
Table 10-32
0
(the padded IV or the GHASHed IV) is provided as the
NOTE
for proper AUX mode specification in this case and to
128
, K), E stands for encryption operation, and K
31
1)
1
; otherwise the IV is hashed using the
0
is denoted E(Y
Freescale Semiconductor
0
, K), and is used
Table
10-35.
0
is