STSAFEA-120: AES CCM Start Decryption command ends up in invalid RMAC if no counter associated to the key
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 65/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- c
- Ambito
- embedded-iot, security
Direzione di ricerca
Start at the stsafea_aes_ccm_decrypt_start response-frame construction and trace how the optional counter element is read when response encryption is enabled. Exercise the no-counter and counter-associated cases with and without a counter buffer; done means RMAC verification succeeds and counter data is handled according to the counter-presence flag.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Normally, start CCM decryption response looks like this:
- Plaintext
- Bit of counter presence + 7 bits of padding
- Counter value.
However, according to user manual, counter value is present in response message only when such counter is associated with used key.
In stsafea_aes_ccm_decrypt_start, frame element for counter value is always allocated.
It is not a problem when no response encryption is used, just this frame element receives some random value from I2C buffer.
Normally, user don't call this function with the counter buffer pointer, this frame element data just ends up in alt_counter variable and gets discarded.
But, if response encryption is used, things get complicated. In this case, RMAC is added right after the last message element.
In result, such RMAC is read as counter value and gets discarded. RMAC verification uses 4 bytes after "counter" bytes in response frame, which are some residues in I2C buffer after previous commands and verification fails.
Moreover, in case when key has associated counter and user calls this function without pointer to counter buffer, counter value just gets discarded.
It means that user will receive some encrypted data, but nonce will be incorrect.
So, normally user is supposed to know key information (and counter presence) before starting the encryption.
Based on this assumption, I propose the following solution:
stse_ReturnCode_t stsafea_aes_ccm_encrypt_start(
stse_Handler_t *pSTSE,
PLAT_UI8 slot_number,
PLAT_UI16 Nonce_length,
PLAT_UI8 *pNonce,
PLAT_UI16 total_associated_data_length,
PLAT_UI32 total_message_length,
PLAT_UI16 associated_data_chunk_length,
PLAT_UI8 *pAssociated_data_chunk,
PLAT_UI16 message_chunk_length,
PLAT_UI8 *pPlaintext_message_chunk,
PLAT_UI8 *pEncrypted_message_chunk,
PLAT_UI8 *pCounter_presence,
PLAT_UI32 *pCounter) {
stse_ReturnCode_t ret;
PLAT_UI8 cmd_header[STSAFEA_EXT_HEADER_SIZE] = {STSAFEA_EXTENDED_COMMAND_PREFIX, STSAFEA_EXTENDED_CMD_START_ENCRYPT};
PLAT_UI8 rsp_header;
PLAT_UI8 alt_counter_presence;
/* - Check stsafe handler initialization */
if (pSTSE == NULL) {
return (STSE_SERVICE_HANDLER_NOT_INITIALISED);
}
if ((pNonce == NULL) ||
(pAssociated_data_chunk == NULL && associated_data_chunk_length != 0) ||
(pAssociated_data_chunk != NULL && associated_data_chunk_length == 0) ||
(pPlaintext_message_chunk == NULL && message_chunk_length != 0) ||
(pPlaintext_message_chunk != NULL && message_chunk_length == 0) ||
(pEncrypted_message_chunk == NULL && message_chunk_length != 0) ||
(pEncrypted_message_chunk != NULL && message_chunk_length == 0)) {
return (STSE_SERVICE_INVALID_PARAMETER);
}
/
/* - Prepare CMD Frame */
stse_frame_allocate(CmdFrame);
stse_frame_element_allocate_push(&CmdFrame, eCmd_header, STSAFEA_EXT_HEADER_SIZE, cmd_header);
stse_frame_element_allocate_push(&CmdFrame, eSlot_number, 1, &slot_number);
stse_frame_element_allocate_push(&CmdFrame, eNonce_length, STSAFEA_GENERIC_LENGTH_SIZE, (PLAT_UI8 *)&Nonce_length);
stse_frame_element_allocate_push(&CmdFrame, eNonce, Nonce_length, pNonce);
stse_frame_element_allocate_push(&CmdFrame, eTotal_associated_data_length, STSAFEA_GENERIC_LENGTH_SIZE, (PLAT_UI8 *)&total_associated_data_length);
stse_frame_element_allocate_push(&CmdFrame, eTotal_message_length, 4, (PLAT_UI8 *)&total_message_length);
stse_frame_element_allocate_push(&CmdFrame, eAssociated_data_length, STSAFEA_GENERIC_LENGTH_SIZE, (PLAT_UI8 *)&associated_data_chunk_length);
stse_frame_element_allocate_push(&CmdFrame, eAssociated_data, associated_data_chunk_length, pAssociated_data_chunk);
stse_frame_element_allocate_push(&CmdFrame, eMessage_length, STSAFEA_GENERIC_LENGTH_SIZE, (PLAT_UI8 *)&message_chunk_length);
stse_frame_element_allocate_push(&CmdFrame, ePlaintext_message, message_chunk_length, pPlaintext_message_chunk);
/* - Prepare RSP Frame */
stse_frame_allocate(RspFrame);
y stse_frame_element_allocate_push(&RspFrame, eRsp_header, STSAFEA_HEADER_SIZE, &rsp_header);
stse_frame_element_allocate_push(&RspFrame, eEncrypted_message, message_chunk_length, pEncrypted_message_chunk);
stse_frame_element_allocate_push(&RspFrame, eCounter_presence, 1, pCounter_presence);
// Presume that if user does not provide a buffer for counter the key does not have counter associated
stse_frame_element_allocate_push(&RspFrame, eCounter, pCounter != NULL ? STSAFEA_COUNTER_VALUE_SIZE : 0, (PLAT_UI8 *)pCounter);
if (pCounter_presence == NULL) {
eCounter_presence.pData = &alt_counter_presence;
}
/* - Swap byte order */
stse_frame_element_swap_byte_order(&eNonce_length);
stse_frame_element_swap_byte_order(&eTotal_associated_data_length);
stse_frame_element_swap_byte_order(&eTotal_message_length);
stse_frame_element_swap_byte_order(&eAssociated_data_length);
stse_frame_element_swap_byte_order(&eMessage_length);
/* - Perform Transfer*/
ret = stsafea_frame_transfer(pSTSE,
&CmdFrame,
&RspFrame);
if (*(pCounter_presence.Pdata) != 0) {
if (pCounter != NULL) {
stse_frame_element_swap_byte_order(&eCounter);
} else {
// Key have associated counter, but user did not provide buffer for it - it is an error
ret = STSE_WRONG_KEY_TYPE;
}
}
return ret;
}
Basically - if user does not provide buffer for counter - presume there's no associated counter, don't try to read it.
At the end of reception, check counter presence flag - if counter is present but user did not provide buffer - that's an error.
- Lingua principale
- C
- Stelle
- 15
- Fork
- 12
- Merge medio
- 1g 5h
- PR unite (30g)
- 11
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di STMicroelectronics/STSELib
-
Max `pBuffer` size for `stse_data_storage_update_data_zone()` unclear due to hidden overhead bytesAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
STMicroelectronics/STSELib#84 · 4 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
# Bug: `stse_perso_info_t` AC status 2-bit mask truncates valid AC valuesForse di nuovo libera @Grom- l’ha presa 201 giorni fa e non c’è nessuna pull request aperta. Apertabug
STMicroelectronics/STSELib#69 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
`stse_platform_Crc16_Accumulate()` is not safeForse di nuovo libera @nils-cercariolo-st l’ha presa 189 giorni fa e non c’è nessuna pull request aperta. Aperta
STMicroelectronics/STSELib#65 · 3 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
STSAFE A120: Reprovisioning is successful, but returns error STSE_INVALID_C_MACForse di nuovo libera @Grom- l’ha presa 333 giorni fa e non c’è nessuna pull request aperta. Apertabug
STMicroelectronics/STSELib#47 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di STMicroelectronics/STSELib
Issue simili
-
bug good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
enhancement
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
FujiNetWIFI/fujinet-lib#122 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 12 giorni
-
bug format I/O medium priority rt_lib
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100