Please look at my comments below.
1.
You may look at the Platform SDK - it contains an example regarding blob using.
"The i.MX6 Platform SDK is located at:
Below is SDK link :
https://www.freescale.com/webapp/Download?colCode=i.MX6_PLATFORM_SDK&location=null
Summary page :
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp=1&tab=Design_Tools_Tab
2.
There is “sm_test.c” (Linux) example (located at "drivers/crypto/caam/sm_test.c")
for testing encapsulating and decapsulating of black keys.
3.
Also, please look at the enclosed example : simple job that will decrypt
a 1024-byte message using AES in CBC mode. I hope it helps.
[00] B080000F jobhdr: stidx=0 len=15
[01] 12200010 ld: ccb1-ctx len=16 offs=0
[02] 00000002 ptr->@0x225a84662
[03] 25A84662
[04] 02000010 key: class1-keyreg len=16
[05] 00000001 ptr->@0x1e767e1b5
[06] E767E1B5
[07] 8210010C operation: cls1-op aes cbc init-final dec
[08] 22120400 fifold: class1 msgdata-last1 len=1024
[09] 00000002 ptr->@0x23ab4850a
[10] 3AB4850A
[11] 60700000 fifostr: msgdata ext
[12] 00000004 ptr->@0x4de37d42c
[13] DE37D42C
[14] 00000400 extlen=1024
The steps involved are:
[01] Load the CBC IV into the Class 1 Context Register
[04] Load the 128-bit AES key into the Class 1 Key Register
[07] Configure the AESA CHA to decrypt with the CBC mode
[08] Read 1024 bytes of input data with the FIFO LOAD command. The data will be
directed to the Class 1 Alignment Block, and the 'last data' flag will be presented
along with the end of it.
[11] Store the deciphered data with the FIFO STORE command. The 'ext' flag means
that the length field in the first word is not used. Instead, the length comes after the
pointer. The class field value is not interpreted when data source/type is 'msgdata',
which means the OFIFO.
This is a good model for data encryption and decryption. If not all of the data is passed
through at once, but processing will continue in other job(s), it might be necessary to
store the context register as the last step of the descriptor. How many bytes to store is
dependent upon the algorithm and mode. This requirement will also affect the 'algorithm
state' value, as init-final is proper for a complete message. RC4 (the AFHA) has a
separate solution in this regard, as the 'context' is 258 bytes (256 bytes of key material of
the RC4 SBox and 1-byte each of the context pointers i and j).
Below are some details how to create a Black Key :
Load the desired key into a key register, (Class 1,Class2, PKHA E, or AFHA Sbox),
using the Key command with the NoWriteBack bit cleared, and then write out the
key register using the FIFO Store command.
The FIFO Store command OutputDataType field is used to specify the source of
the key, the encryption algorithm (AES-ECB or AES-CCM) and the KEK (either JDKEK
or TDKEK). Note that only a Trusted Descriptor may specify using the TDKEK for creating
a Black Key. Otherwise, an error will result.
A Black Key will be larger than a plaintext key. When using AES-CCM mode, the Black Key
will be 12 bytes longer than the plaintext key. Six of the extra bytes contain the nonce for
the Black Key, and the other six bytes contain a 48-bit integrity check tag. If the tag is
incorrect when a descriptor loads an AES-CCM Black Key, the descriptor will stop with an error.
When loading a Black Key into a key register using the Key command, the value
specified in the length field is the length of the plaintext key, not the size of the Black
Key buffer. When creating a Black Key using the FIFO Store command, the value in the
length field is the length of the plaintext key. The buffer must be large enough to hold the
encrypted key plus the additional padding.
Have a great day,
Yuri
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------