>

Keyhold

My pre university project. My ideas for this project have expanded so this is my current project as of now.

Github Project

Demos

Inspiration

I wanted to get a little deeper into embedded and make something with more utility unlike the last flipper application I made. Making that application served as a stepping stone for this. I thought it would be cool if you could send encrypted messages over radio, bluetooth, nfc, etc with the Flipper Zero and have a encryption key manager on the device.

Keyhold is a cryptographic key manager++ on your flipper zero device. You may generate keys and encrypt messages for other people using asymmetric encryption with x25519. Encrypted messages can be sent over the sub ghz device on the flipper zero. Messages may also be decrypted. Bluetooth security is also a feature as keeping your private keys stored on a SD card may be risky due to theft. So, you can encrypt all of your private keys (via ChaCha20) and the encryption key will be on the serial characterstic over bluetooth. If you decide to encrypt your private keys, you will need to authenicate over bluetooth (on the serial characterstic) using the encryption key for everytime you turn on the device. Authenticating should decrypt your private keys and store the decrypted keys in memory, and should stay in memory even if you leave the application; this is so you only need to authenticate when you turn on the device, which shouldn’t be often considering that the flipper zero can stay on for a very long time. Ofcourse, this is still vulnerable because the private keys are easily visable in memory, but this is still better than keeping them raw on storage.

Project Plan

  • Generate key pairs as “identities” 🟢
  • Save identities like contacts 🟢
  • Identity sharing
    • NFC tap to do key exchange ⚪
    • Same ways of import/export of encrypted messages, just needs to be added to UI.
  • Import/Export features of encrypted messages
    • Save as file 🟢
    • Import file 🟢
    • Send over radio 🟢
    • Receive over radio ⚪
  • Message encryption
    • file encryption 🟢
    • text encryption 🟢
  • Encryption options
    • Anonymous encryption with ephemeral public key 🟡
    • Encrypter contact/identity needs to be known for decryption 🟢
  • Security
    • TPM Chip ⚪
    • Keys on storage encrypted and restored via bluetooth with phone 🟢
  • Binary schema for data
    • Protobuf â­•
    • Own implementation 🟢
  • Major refactor of code base

More In Depth Notes

Security

Because identities are stored on the SD card, which is easily removable/stealable, there is a security risk as your private keys can be taken easily. I have two ideas to fix this. The first is using a TPM chip through the Flipper Zero’s GPIO pins. Off the bat, I am not in the mood to write drivers for the firmware for this from scratch. The other idea, which is most likely what I plan on doing, is having the identity files on a encrypted image on the SD card. A mobile device through bluetooth can then unlock the image and the application would load the data of the files into the ram of the device, the image stays encrypted. Once the data is on the ram, it will stay like that until the device is turned off. Data kept in the ram is generally secure. The pros of this is, you only need to unlock this once, and then you can keep the flipper on for a week like some people do.

Binary Schema

I started setting up Protobuf but after some consideration, I decided to make my own implementation of how the data of messages, identities, etc should be formatted. A rough explanation of it can be seen here .

Encryption method

This application uses monocypher . An Identity consists of a public key and maybe a private key (if it’s an identity that belongs to you). Identities that are not imported (generated through application) are made by first making a 32 byte random private key using the firmware’s random byte generator . The public key can then be generated via monocypher’s X25519 public key generator. Two identities can be used to do a X25519 key exchange which would give us a shared secret. We then hash the shared secret with the HChaCha20 hashing function. We use this hash to preform encryption/decryption. Nonce is random 24 bytes; with a nonce this big, there is no need to use a counter. Mac/tag is 16 bytes.

Anonymous encryption will be done using a ephemeral key . We do this by generating one-time-use Identity. This unknown non-named identity will be used for the rest of the encryption process, and the encrypted message will include alongside it its ephemeral public key. The recipient, receiving the message, in whatever way, will use the included ephemeral public key when doing a key exchange for the decryption process. I got this idea from seeing how monocypher-py implemented their “SealedBox.”

Major refactor

A major refactor of the codebase is needed. When you don’t have a good idea of what you want the application to be at the end from the beginning, you kind of just tape everything together as you go. Once I am satisified with all the features and capabilities of this application, I plan on refactoring the codebase.