2

Basically, I have a Raspberry Pi that is installed in a car. If the car gets stolen, how can I make sure that the files can't be decrypted?

The Raspberry Pi contains a Python script that records movements in the car. When a sequence is finished, it is then encrypted, so the script has to have access to the encryption key.

The Python script also needs to decrypt the file, because it has to be able to send the sequence to a client via a network in HTTPS. It has to have access to the decryption key.

If the key(s) are hard coded in the script, it will be easy for the stealer to decrypt the files.

Could I use a user password generated key (I have seen some people talking about PBKDF2)? If so, how would it work if the client sends that password via HTTPS to the server (the server being the Raspberry Pi)? The generated key would still need to be stored somewhere, so I don't see how it could help.

7

If your Raspberry Pi doesn't need to decrypt the data use asymmetric encryption (public/private key) instead. Then the public (encrypting) key can be used on the Raspberry Pi and only when it arrives at your client (via HTTPS) can it be decrypted with the private key.

I haven't used Python in this manner but the following URL seems like a good start:

Laurent Luce's Blog - Python and cryptography with pycrypto

EDIT: Since your Raspberry Pi needs both encrypt and decrypt capabilities, the most secure method is to still incorporate asymmetric encryption. Just like your current method of using symmetric encryption (shared key), one has to be careful with where to store the keys. By incorporating smart cards, the private (decrypting) key would be stored on the card itself. Just like having a key to start your car, a smart card could be required to use your Raspberry Pi. While this would increase your costs (purchase of smart card, card reader, etc), it is the most secure option.

If this solution is not viable, then full disk encryption is your best bet as mentioned by pjc50.

  • Question has been edited with more info. – Neil Smithline Jan 21 '16 at 5:37
  • This answer is still good after your edits Neil. If your server must receive the data in decrypted form, then consider installing another server (AWS, DigitalOcean etc) to which the car's Pi sends the encrypted data. The intermediate server then decrypts and forwards to your server over HTTPS. That way, you store the public key in the car to encrypt and the private key in the intermediate server. If your car is stolen, the data on the Pi is encrypted. – garethTheRed Jan 21 '16 at 7:59
  • As stated in my OP, the Raspberry Pi needs to encrypt and decrypt. Encrypt once a video sequence is finished and decrypt before sending a client this sequence. – maximedupre Jan 22 '16 at 2:14
  • Consider incorporating smart cards. I can provide more details later as I'm on a mobile. – user2320464 Jan 22 '16 at 6:55
  • 1
    @maximedupre Frankly, why does the Pi need to decrypt? You're trying to solve a fundamentally unsolvable problem if the Pi can also decrypt the data. If the Pi can decrypt, then an attacker can gain access to the key. So the solution is to figure out a way to have the Pi NOT decrypt the data. Security is about flexibility in design, and integrating that into the problem statement. – Steve Sether Jan 22 '16 at 19:14
1

Depending on how critical this is and the likelihood of a sophisticated attack (your threat model), you could try the car radio approach:

Use either full-disk encryption or an encrypted database to store the data. The Pi will then need a password entered every time it boots. To save the user having to do this every time they start the car, add an SPI serial SRAM to the Pi with the password in it. The SRAM will forget the data whenever it loses power. Put it on a separate power supply always connected to the battery (presumably the Pi isn't), and put the whole thing in a case with a tamper microswitch monitoring the lid. Opening the lid removes power from the SRAM and the Pi, causing the password to be forgotten.

It's not 100% proof against a dedicated attacker, but it should work reasonably well against regular thieves.

  • There can't be full-disk encryption, as the user has no way of entering a password directly on the Pi (there is no screen and keyboard attached to it). The only way the user can send a password to a Pi is via an HTTPS request, which is why the password needs to be stored on the Pi. The user password could be used as the password for an encrypted database, but the first time, when the user creates the password, the python server would need to create a DB programatically and I don't know how secure this is ^^. – maximedupre Jan 22 '16 at 2:49
  • You stopped reading at the mention of FDE and ignored the bit about the SRAM! – pjc50 Jan 22 '16 at 9:30
  • No I read everything! It didn't seem like a solution when I read it yesterday, but now it kinda makes sense. I will analyse this solution a bit more to get to a conclusion. There might be a problem if the car and power supply has no more energy. When the car starts back, since the password has been cleared, there is no way of verifying if the key the user is sending is the good one or not. – maximedupre Jan 23 '16 at 3:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.