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.

CC2642R: How to enable partial EdDSA signature

Part Number: CC2642R


The current EdDSA driver requires the entire message to be provided at once for signature verification. The following outlines how the EdDSA driver may be modified to support receiving the signed message in pieces. The outline is for the signature verification operation. Modification of the signature generation operation is very similar. Note that this outline is based on code review and has not been implemented and thus is untested.

 

  • Add the following new function declarations to EDDSA.h:
    • int_fast16_t EDDSA_verifyStart(EDDSA_Handle handle, EDDSA_OperationVerify *operation)
      • For simplicity of the outline, the EDDSA_OperationVerify structure is reused for verifyStart. However, the preHashedMessage and preHashedMessageLength parameters will not be used.
    • int_fast16_t EDDSA_getSHA2Handle(EDDSA_Handle handle, SHA2_Handle * sha2Handle)
    • int_fast16_t EDDSA_verifyFinish(EDDSA_Handle handle)
  • The implementations of the three new functions will be placed in the eddsa/EDDSACC26x2.c file.
  • The approach is to take the existing EDDSA_verify() function and the EDDSACC26X2_runVerifyFSM functions and modify/break them into components to support the new APIs.
  • The _verify() function performs the following steps
    1. Validates key sizes.
    2. Waits for the PKA access semaphore
    3. Copies function input parameters to the driver instance’s object
    4. Initialize statemachine state and other object state
    5. Creates a SHA2 driver object and stores a reference to that object in the driver instance’s object
    6. Configures interrupts and power
    7. Enables the PKA interrupt, which causes the interrupt to run and in turn starts execution of the Verify FSM
    8. Calls waitForResult

 

  • We can map those steps (A-H) into the new APIs. Note that some of the steps must be performed in more than one of the new APIs. Implement the following APIs in eddsa/EDDSACC26x2.c:
    • EDDSA_verifyStart():
      • steps A, C, D, E, F, G, H (all steps except B)
    • getSHA2Handle ():
      • Have it populate the sha2Handle parameter with the sha2Handle object value stored in the EDDSA object: sha2Handle = handle->object->sha2Handle
      • No steps from the _verify() function are needed
    • verifyFinish():
      • steps B, F, G, H
  • Now the state machine in EDDSACC26X2_runVerifyFSM() needs to be modified. The outline here will result in the original EDDSA_verify() function no longer working. Additional work will need to be done if it is desired to support the original _verify() function as well as the new APIs.
    • In EDDSACC26X2_runVerifyFSM(), modify EDDSACC26X2_FSM_VERIFY1_HASH_PUBLIC_KEY state to return EDDSA_STATUS_SUCCESS instead of EDDSACC26X2_STATUS_FSM_RUN_PKA_OP.
    • In eddsa/EDDSACC26x2.h, remove the following enum values from EDDSACC26X2_FsmState
      • EDDSACC26X2_FSM_VERIFY1_HASH_MESSAGE1
      • EDDSACC26X2_FSM_VERIFY1_HASH_MESSAGE2
    • In EDDSACC26X2_runVerifyFSM() remove the two case statements for the removed enum values. Save the contents of the two case statements for reference later.
    • The above modifications should result in the following:
      • EDDSA_verifyStart() should result in the in execution of the first two states of the verify state machine: EDDSACC26X2_FSM_VERIFY1_HASH_SIG_R and EDDSACC26X2_FSM_VERIFY1_HASH_PUBLIC_KEY states. The resulting state after execution of verifyStart should be EDDSACC26X2_FSM_VERIFY1_HASH_FINALIZE
      • EDDSA_verifyFinish() should result in execution of the verify state machine starting with EDDSACC26X2_FSM_VERIFY1_HASH_FINALIZE and continuing to the end of the state machine.

 

How to use this modification

  1. Remember that EDDSA_verify() will no longer work
  2. Call EDDSA_verifyStart() and verify the return value is EDDSA_STATUS_SUCCESS
    1. Note that the preHashedMessage and preHashedMessageLength members of the operational struct will not be used.
  3. Call EDDSA_getSHA2Handle() to obtain the SHA2 driver handle.
  4. Use the SHA2 driver handle to reimplement the EDDSACC26X2_FSM_VERIFY1_HASH_MESSAGE1 and EDDSACC26X2_FSM_VERIFY1_HASH_MESSAGE2 states, feeding in message data as appropriate for overall system design constraints.
  5. Do _not_ call SHA2_finalize (the EDDSA verify State machine will take care of finalizing the hash)
  6. Call EDDSA_verifyFinish()