Spark Core och Android Garage öppnare. Minus Spark molnet. (11 / 19 steg)
Steg 11: Kryptering/dekryptering och Session etablering
Detta steg beskriver detaljerna i hur SecureChannelServer klass implementeras.
Används symmetrisk delade-nyckel security. Detta innebär att en gnista och klienten Android app måste dela samma hemliga nyckeln för att prata med varandra.
Huvudnyckel
128-bitars huvudnyckeln måste tillhandahållas av dig i denna fil: core-firmware/libraries/garage/master_key.h. Här är ett exempel på vad det kan se ut:
#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 används för kryptering av trafiken. Utmaningen baserad, tidsinställda session tokens används för att förhindra Replay-attacker. Session tokens är giltig i 5 sekunder efter slumpmässiga utmaning nonce utfärdas till Android app.
Två krypto primitiver genomförs för att kryptera trafiken från Android till Spark, och vice versa.
AndroidRequest(COMMAND)
Android 1) generera slumpmässiga IV_Send [16]
Android 2) skicka [Message_Length [2], IV_Send [16], AES_CBC (Master_Key, IV_Send, kommando), < === HMAC(Master_Key)]
Gnista 1) kontrollera att HMAC (Master_Key, NYTTOLASTEN) matchade den mottagna HMAC
Gnista 2) dekryptera och passera befalla till konsumenten
SparkResponse(RESPONSE)
Gnista 1) generera slumpmässiga IV_Response [16]
Gnista 2) skicka [Message_Length [2], IV_Response [16], AES_CBC (Master_Key, IV_Response, svar), < === HMAC(Master_Key)]
Android 1) kontrollera att HMAC (Master_Key, NYTTOLASTEN) matchade den mottagna HMAC
Android 2) minskas och processen svar
Dessa två funktioner uppnå följande:
- Angriparen kan inte se meddelanden som oformaterad text
- Angriparen kan inte ändra den krypterade trafiken på något sätt
- Angriparen kan inte skilja mellan krypterade meddelanden, b/c samma klartext ser annorlunda ut varje gång det är krypterat
Återstående problemet är att vi är fortfarande utsatta för repetitionsattacker, eftersom angriparen kan fånga krypterade meddelanden, vänta tills vi är borta och spela upp det för att öppna garageporten. För att ta upp denna fråga utnyttjade jag en utmaning baserad, kryptografiska tillfälligt protokoll.
Session etablering
Följande algoritm refererar till de två funktionerna definieras ovan.
Android 1) AndroidRequest("NEED_CHALLENGE")
Gnista 1) Använd PRNG att generera slumpmässiga utmaning [16]
Gnista 2) beräkna conversationToken == HMAC (Master_Key, Challenge[16])
Gnista 3) startar 5 andra timer
Gnista 4) SparkResponse(Challenge[16])
Android 2) beräkna conversationToken == HMAC (Master_Key, Challenge[16])
Android 3) AndroidRequest (conversationToken, kommandot])
Gnista 5a) se till att conversationToken matchade den mottagna en. I så fall köra kommandot, ogiltigförklara conversationToken och SparkResponse (conversationToken, DOOR_STATUS])
Gnista 5b) om timer löper ut, ogiltigförklara conversationToken
Android 4) se till att conversationToken svar matchade, uppdatera skärmen och ogiltigförklara conversationToken
Detta protokoll avbildas också i det bifogade sekvensdiagrammet.