Timeline for AES-GCM for Securing Bluetooth Low Energy Application
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 29, 2017 at 1:46 | vote | accept | arahaeldor | ||
| Nov 29, 2017 at 1:46 | |||||
| Nov 9, 2017 at 1:27 | comment | added | arahaeldor | Regarding the contributory behavior, I have decided to use more standard setup like TLS handshake which exchange random number from both parties, but in my case there would be no certificate verification. The other thing is when both device derive its session key, I would use the HKDF for deriving the session key using exchanged random from both as salt and long term key as Input Keying Material. | |
| Nov 9, 2017 at 1:20 | comment | added | arahaeldor | yes following your suggestion, I have a plan to prepare the production so that each BLE device would have different long term key and it will be programmed and be locked from JTAG dump/read using the secure feature from the processor that I use. Maybe it still can be cracked by someone with very high expertise but at least it is only that device which is compromised. Regarding the good PKI, I plan to use it for the version 2 of the device because I already have schedule to follow for current version. | |
| Nov 7, 2017 at 19:16 | history | edited | Squeamish Ossifrage | CC BY-SA 3.0 |
Typeface fairy!
|
| Nov 7, 2017 at 17:00 | history | answered | Lery | CC BY-SA 3.0 |