Stap 11: Codering/decodering en sessie vestiging
Deze stap wordt beschreven op de bijzonderheden van de wijze waarop de SecureChannelServer klasse wordt geïmplementeerd.
Symmetrische gedeelde-sleutel beveiliging wordt gebruikt. Dit betekent dat de kern van de vonk en klant Android app dezelfde geheime sleutel delen moeten om te praten met elkaar.
Hoofdsleutel
De 128-bits hoofdsleutel moet worden verstrekt door u in dit bestand: core-firmware/libraries/garage/master_key.h. Hier is een voorbeeld van wat dat eruit zou kunnen zien:
#ifndef LIBRARIES_GARAGE_MASTER_KEY_H_ #define LIBRARIES_GARAGE_MASTER_KEY_H_ const uint32_t MASTER_KEY[4] = {0x12345678, 0x12345678, 0x12345678, 0x12345678}; #endif /* LIBRARIES_GARAGE_MASTER_KEY_H_ */ AES-128 wordt gebruikt voor het coderen van het verkeer. Uitdaging gebaseerd, getimede sessie tokens worden gebruikt ter voorkoming van Replay aanvallen. Sessie-munten zijn geldig gedurende 5 seconden nadat de nonce willekeurige uitdaging wordt afgegeven aan de Android app.
Twee crypto primitieven zijn geïmplementeerd voor het coderen van het verkeer van Android naar vonk, en vice versa.
AndroidRequest(COMMAND)
Android 1) Generate random IV_Send[16]Android 2) Send [Message_Length[2], IV_Send[16], AES_CBC(Master_Key, IV_Send, COMMAND), <==== HMAC(Master_Key)]Spark 1) Verify that HMAC(Master_Key, PAYLOAD) matched the received HMACSpark 2) Decrypt and pass COMMAND to consumer
SparkResponse(RESPONSE)
Spark 1) Generate random IV_Response[16]Spark 2) Send [Message_Length[2], IV_Response[16], AES_CBC(Master_Key, IV_Response, RESPONSE), <==== HMAC(Master_Key)]Android 1) Verify that HMAC(Master_Key, PAYLOAD) matched the received HMACAndroid 2) Decrypt and process RESPONSE
Deze twee functies bereiken het volgende:
- De aanvaller kan niet zien de leesbare tekst berichten
- De aanvaller wijzigen niet de gecodeerd verkeer op enigerlei wijze
- De aanvaller kan niet zeggen het verschil tussen gecodeerde berichten, b/c hetzelfde leesbare tekst ziet er anders uit elke keer dat het wordt gecodeerd
Het resterende probleem is dat we nog steeds kwetsbaar voor Replay-aanvallen, omdat de aanvaller kan vangen een geldige gecodeerd bericht, wachten tot we verdwenen zijn en het afspelen om te openen de garagedeur. Om aan te pakken dit probleem gebruikt ik een uitdaging gebaseerd, cryptografische nonce protocol.
Sessie vestiging
Het volgende algoritme verwijst naar de twee functies hierboven omschreven.
Android 1) AndroidRequest("NEED_CHALLENGE")Spark 1) Use PRNG to generate random Challenge[16]Spark 2) Calculate conversationToken == HMAC(Master_Key, Challenge[16])Spark 3) Start 5 second timerSpark 4) SparkResponse(Challenge[16])Android 2) Calculate conversationToken == HMAC(Master_Key, Challenge[16])Android 3) AndroidRequest( conversationToken, COMMAND] )Spark 5a) Make sure that conversationToken matched the recieved one. If so, execute command, invalidate conversationToken and SparkResponse( conversationToken, DOOR_STATUS] )Spark 5b) If timer expires, invalidate conversationTokenAndroid 4) Make sure conversationToken in response matched, update screen and invalidate conversationToken Dit protocol wordt ook afgebeeld in het bijgevoegde sequentiediagram.
