• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 230 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM625: 【OPTEE client Code Devellop】【baseLine: SDK 10.1】 Questions about TI baseline Yocoto built code

Chen Jibin
Prodigy 60 points
Part Number: AM625


Tool/software:

Recently i was trying to develop the OPTEE client(Host) code based on the Yocto built Repo based on the TI SDK10.1 baseline. To accelerate the Dev. process just trying to find out if any pre-coded api-like source code could be used as a reference,

then i found the  <pkcs11_api.h> at the relative path of: /work/sdk/VW_FPK_YOCTO/build/arago-tmp-default-glibc/sysroots-components/aarch64/optee-client/ , at this path  i found the “libckteec.so” .

then i check the corresponding source code “pkcs11_api.c” , i read through most the APIs,the most parts are understandable for me, i got questions for the following two API()

The First one: 

CK_RV C_VerifyInit(CK_SESSION_HANDLE hSession,
           CK_MECHANISM_PTR pMechanism,
           CK_OBJECT_HANDLE hKey)
for this API, hKey (a key handle) just a input, my point this the whold PKCS#11 driver didn't tell me where i could retrieve the KEY HANDLE, i don't even konw where i could generate a my own KEY HANDLE (llike i wanna import the private key known for me then also get the KEY HANDLE known for me). Do you know the Answer?
The Second one:
CK_RV C_Decrypt(CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pEncryptedData,
        CK_ULONG ulEncryptedDataLen,
        CK_BYTE_PTR pData,
        CK_ULONG_PTR pulDataLen)
For this API, i can't really tell  what's the difference on "Input-wise" between I implement AES-ECB method and AER-CBC method, since the latter method require a extra param called "IV" comparing to the former one. Do you know the answer?

Final question is: Could TI counterpart provide Desay a usable demo code based on this PKCS#11 driver (this "libckteec.so" ) for the following scenarios:
(1)"AES-CBC encryption and decrption" , also the corresponding key management (secure storage at RPMB) should be included.  
(2) "Hash based on SHA256"
(3) "ECDSA256 based signature geneartion and verification"also the corresponding key management (secure storage at RPMB) should be included.   
  • 0
    TI__Guru 69970 points

    Hi Jibin,
    Some reference on OPTEE/PKCS11/TA...
    https://static.linaro.org/connect/lvc21/presentations/lvc21-215.pdf
    https://optee.readthedocs.io/en/latest/building/userland_integration.html
    https://optee.readthedocs.io/en/latest/building/trusted_applications.html

    Here're OPTEE xtest suite pkcs11 test code, where you can explore this file to see how various pkcs11 functions are tested within OPTEE.
    https://github.com/OP-TEE/optee_test/blob/master/host/xtest/pkcs11_1000.c

    Please note that OPTEEE is open source community project, for example. OPTEE/PKCS11 is common lib, and support from TI is limited.

    Best,
    -Hong

  • 0 in reply to Hong Guan64
    TI__Expert 3885 points

    Hong, thanks for your clarification. Do we have a clear API list to highlight which specifics APIs within the OPTEE context have been accelerated and enabled by TI's Hardware module accelerator or tifs firmware running on the M4_0 core please? i think this would be helpful to separate the parts where ti should support or else for open source community. 

  • 0
    Prodigy 60 points
    static const CK_FUNCTION_LIST libckteec_function_list = {
        .version = {
            .major = CK_PKCS11_VERSION_MAJOR,
            .minor = CK_PKCS11_VERSION_MINOR,
        },
        .C_Initialize = C_Initialize,
        .C_Finalize = C_Finalize,
        .C_GetInfo = C_GetInfo,
        .C_GetFunctionList = C_GetFunctionList,
        .C_GetSlotList = C_GetSlotList,
        .C_GetSlotInfo = C_GetSlotInfo,
        .C_GetTokenInfo = C_GetTokenInfo,
        .C_GetMechanismList = C_GetMechanismList,
        .C_GetMechanismInfo = C_GetMechanismInfo,
        .C_InitToken = C_InitToken,
        .C_InitPIN = C_InitPIN,
        .C_SetPIN = C_SetPIN,
        .C_OpenSession = C_OpenSession,
        .C_CloseSession = C_CloseSession,
        .C_CloseAllSessions = C_CloseAllSessions,
        .C_GetSessionInfo = C_GetSessionInfo,
        .C_GetOperationState = C_GetOperationState,
        .C_SetOperationState = C_SetOperationState,
        .C_Login = C_Login,
        .C_Logout = C_Logout,
        .C_CreateObject = C_CreateObject,
        .C_CopyObject = C_CopyObject,
        .C_DestroyObject = C_DestroyObject,
        .C_GetObjectSize = C_GetObjectSize,
        .C_GetAttributeValue = C_GetAttributeValue,
        .C_SetAttributeValue = C_SetAttributeValue,
        .C_FindObjectsInit = C_FindObjectsInit,
        .C_FindObjects = C_FindObjects,
        .C_FindObjectsFinal = C_FindObjectsFinal,
        .C_EncryptInit = C_EncryptInit,
        .C_Encrypt = C_Encrypt,
        .C_EncryptUpdate = C_EncryptUpdate,
        .C_EncryptFinal = C_EncryptFinal,
        .C_DecryptInit = C_DecryptInit,
        .C_Decrypt = C_Decrypt,
        .C_DecryptUpdate = C_DecryptUpdate,
        .C_DecryptFinal = C_DecryptFinal,
        .C_DigestInit = C_DigestInit,
        .C_Digest = C_Digest,
        .C_DigestUpdate = C_DigestUpdate,
        .C_DigestKey = C_DigestKey,
        .C_DigestFinal = C_DigestFinal,
        .C_SignInit = C_SignInit,
        .C_Sign = C_Sign,
        .C_SignUpdate = C_SignUpdate,
        .C_SignFinal = C_SignFinal,
        .C_SignRecoverInit = C_SignRecoverInit,
        .C_SignRecover = C_SignRecover,
        .C_VerifyInit = C_VerifyInit,
        .C_Verify = C_Verify,
        .C_VerifyUpdate = C_VerifyUpdate,
        .C_VerifyFinal = C_VerifyFinal,
        .C_VerifyRecoverInit = C_VerifyRecoverInit,
        .C_VerifyRecover = C_VerifyRecover,
        .C_DigestEncryptUpdate = C_DigestEncryptUpdate,
        .C_DecryptDigestUpdate = C_DecryptDigestUpdate,
        .C_SignEncryptUpdate = C_SignEncryptUpdate,
        .C_DecryptVerifyUpdate = C_DecryptVerifyUpdate,
        .C_GenerateKey = C_GenerateKey,
        .C_GenerateKeyPair = C_GenerateKeyPair,
        .C_WrapKey = C_WrapKey,
        .C_UnwrapKey = C_UnwrapKey,
        .C_DeriveKey = C_DeriveKey,
        .C_SeedRandom = C_SeedRandom,
        .C_GenerateRandom = C_GenerateRandom,
        .C_GetFunctionStatus = C_GetFunctionStatus,
        .C_CancelFunction = C_CancelFunction,
        .C_WaitForSlotEvent = C_WaitForSlotEvent,
    };
    From PKCS11_api.c
  • 0 in reply to Chen Jibin
    TI__Guru 69970 points

    Hi Xu,
    As noted on slide #6 from the first link in my last reply
    "PKCS#11 Token in an OP-TEE TA
    Goal: deliver a PKCS#11 solution, reliable and maintained by the OP-TEE community"

    On HW crypto engine support in OPTEE, we communicated with the customer via email in May-2025
    - RNG in OPTEE is supported via HW crypto RNG module
    - Rest of crypto operations in OPTEE is supported via SW implementation
    https://optee.readthedocs.io/en/latest/architecture/crypto.html
    - There's no CPU offloading benefits when running HW crypto engine SAx_UL in OPTEE as OPTEE cannot be preempted

    Best,
    -Hong

  • 0 in reply to Hong Guan64
    Prodigy 60 points

    I understand OPTEE is a opensoure for most part. But the point this for the RPMB part, there is some key modification has to be modified as per the actual hardware platform you should really read through the URL you sent me. That's why i was asking the question....

    For example:

    Point 1:

    To allow Secure Storage to operate securely on your platform, you must define implementations in your platform code for:

    void tee_otp_get_hw_unique_key(struct tee_hw_unique_key *hwkey);

int tee_otp_get_die_id(uint8_t *buffer, size_t len);

    These implementations should fetch the key data from your SoC-specific e-fuses, or crypto unit according to the method defined by your SoC vendor.

    Point 2:

    However notice that, since the RPMB key can only be written once on the controller, it follows that accessing RPMB before securing the board will cause future RPMB accesses to be denied once the board has been secured. To prevent this situation from happening, OP-TEE provides a software hook which platforms shall use to implement its security logic plat_rpmb_key_is_ready()

    Just wonder if there is any points that are hardware platform dependent, TI should help to point them out.

  • 0 in reply to Hong Guan64
    TI__Expert 3885 points

    Hong, kindly please reply the RPMB questions from Jinbin from the hardware platform dependency angle, especially the necessary 

    tee_otp_get_hw_unique_key and tee_otp_get_die_id Core APIs have been clearly highlighted by the OPTEE spec/document. And it would be better to point Jinbin to the right source code to identify the ti's implementation as well.
    appreciate.