1
$\begingroup$

This question stems from a UX problem where I want to allow the user to input their PIN only one single time when they open up an mobile app. Here are some properties of the application to provide some context.

  1. The user is on a mobile device with a bluetooth smart card reader
  2. The data stored on the device is PII-data and national regulations (Sweden) state that the data must only be accessible via secure 2-factor auth
  3. I'm planning to use a hybrid cryptosystem for the sensitive data
  4. The symmetrical key will be decrypted with the smart card
  5. I want to store the information for offline use so an embedded web browser for an online webapp does not cut it.
  6. There will be multiple files that requires encryption, media for example will all be individual files.

Given these prerequisites I plan to have one symmetrical key defined for each unique user per app install.

This means any data synced to that app install for a single user will use the same symmetric key. This way I want to decrypt all files related to one user with the same symmetrical key. I consider it something similar to an OAuth2 token (but without the renewal part right now).

Please help me assess if there are any security flaws with this model!

$\endgroup$
0
$\begingroup$

Reusing the symmetric key in a hybrid cryptosystem may or may not be safe depending on the cryptosystem. To give a simple example, suppose a system was designed to use a single-use symmetric encryption key with a cipher in CTR mode, and it is now extended in such a way that the symmetric key is now reused for several messages but still shared with the same party. (If the protocol changes to share the symmetric key with a different party each time, that obviously affects security.) If the cryptosystem uses a random initial counter value, the same key could be used more than once without affecting security. If the cryptosystem uses the initial counter value 0, that's perfectly fine with a single-use key but catastrophic if the key is reused.

Having data which is encrypted with a long-term key which is unlocked at the beginning of a session is perfectly standard. Full-disk encryption does this, for example — typically the same key is used to encrypt all the successive versions of all the blocks of the encrypted device.

The basic idea of storing a symmetric key in a smartcard and having the card deliver it to the computer (a phone in your case) when the user enters a PIN is sound. The computer should keep the key only in RAM, and your application should wipe the key after a delay. How long a delay is a compromise between UX and security and depends on the nature of the data; you have to balance user convenience with the risk of the device being stolen.

There may or may not be value in encrypting each file with a different key. Having the card do the whole encryption and decryption is probably out of the question for both performance and UX reasons (the card would have to be present during all file accesses). But having the card release only one per-file key at a time may or may not make sense. You do need per-file keys if there is ever a reason why access to different files should be subject to different rules (e.g. you might want different timeouts on different files' keys). Per-file keys also offer better protection against a limited-time compromise (e.g. a rogue app that can extract the key from your app's memory but not inject code into your app). You can have per-file keys in two ways: either there's a single master key which the card releases upon request, and the computer does the key derivations; or the master key never leaves the card and the computer asks the card to derive each file's key when that file is accessed.

Whatever algorithm you pick, make sure to use it properly, in particular with a random IV for each file (stored at the beginning of the file). Note that if a file changes, the new version of the file must use a new random IV if it's encrypted with the same key.

You should use authenticated encryption (e.g. GCM), to prevent active attacks where a rogue app on the computer tries to decrypt bad data. Note that this means that a file must be decrypted (+authenticated) as a whole; you may need to split large files. Note also that authenticating a file only proves that it's some valid version of the file; it could be an old version, or it could be valid content of a different file unless you authenticate the relationship between a file's name and its content.

As a final note, modern major mobile platforms include protected environments that can store encrypted files with some protection against third-party applications and some form of user authentication (PIN or fingerprint) required for access (keychain on iPhone/iPad, keymaster on high-end Android phones and tablets). This satisfies the requirement of two-factor authentication. While it doesn't offer as a good a protection against attacks against the key at rest, it offers a better protection over what is a significant threat here, which is a rogue app on the device exploiting an OS bug to extract the key while it's in use. With the smartcard approach, the key is in your app's memory; with a keychain/keymaster approach, the key remains inside a protected environment, although the decrypted data would be visible to the rogue app anyway.

$\endgroup$
  • $\begingroup$ Thank you for the detailed descriptions. Very good point about the IVs. I have some follow up comments. I'll split the up into individual comments for brevity. $\endgroup$ – Magnus Apr 5 '17 at 4:54
  • $\begingroup$ Type of cards keys I cannot affect and those are asymmetrical key to decrypt a symmetrical user+appinstall key that is used for the file encryption, but I don't think that changes your argument? $\endgroup$ – Magnus Apr 5 '17 at 4:54
  • $\begingroup$ As for GCM I think there is no problem there, I don't think I need partially decrypted files or streaming cryptos. However I'm not following why I would need to split files? In order to save memory? $\endgroup$ – Magnus Apr 5 '17 at 4:56
  • $\begingroup$ As for the regulations I perhaps should have added that the Smart Cards are actually nationally issued e-identity cards (much like military CAC cards in the US). So I cannot substitute them with other authentication schemes such as a fingerprint reader. I need to make sure the sensitive data is only readable by an authorized individual. I do the authorization up front by encrypting user specific data files that only the correctly authenticated individual can decrypt with their Smart Card. $\endgroup$ – Magnus Apr 5 '17 at 4:56
  • $\begingroup$ Lastly a question. You mentioned that filesystem encryption schemes use something similar to what I was proposing. Are you aware of any good library or tool candidates I could reuse? I see the potential of skipping reinventing the wheel. $\endgroup$ – Magnus Apr 5 '17 at 5:03

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.