I am currently working on a hardware project that will utilize the native USB and keyboard emulation capabilities of the Teensy device. Essentially, the user will store an encrypted password database on a mounted SD card that the Teensy will read and send to the host computer. This prevents the requirement of storing passwords in browsers, or certain managers.

However, I'm having a very hard time finding a secure way of encrypting it.

As of right now, I'm using the SHA256 hash value of the pin code as the AES-256 key.

  1. Pin Code - I am currently using a 4x4 matrix keypad to allow the user to enter a pin code immediately after the device boots up. The available pins for the passcode are (14 characters): 0 1 2 3 4 5 6 7 8 9 A B C D This limited keyspace means that passwords need to be much longer in order to maintain the same amount of security. Otherwise, this is my favorite option. It also allows me to use the keypad for navigation. Adding a salt would better, but exhausting the entire keyspace is very fast.

  2. Fingerprint - This is a neat idea that could potentially be leveraged to allow different users to share a single hardware device. However, this doesn't aid in encryption. I don't know of any implementation of a symmetric encryption algorithm using a fingerprint, or a direct derivative thereof, as a key.

  3. YubiKey - This isn't necessarily a bad option, as it would provide a secure way of handling encryption/decryption of such devices, but that means it requires additional hardware for users. Also, I actually planned on implementing the Yubikey emulation library so the device could, itself, be used as a YubiKey.

Is there a feasible way? Or is this project flawed from the start?

  • $\begingroup$ When performing the hashing to derive the key, you should use password hashing functions like bcrypt and scrypt instead of a plain hash. Password hashes are designed to be slow, and utilizing these will slow down offline brute force attacks. $\endgroup$
    – rlee827
    Aug 24 '18 at 22:49
  • $\begingroup$ Neat about the military! However, it's also made of open sourced components and after a quick google search, this doesn't make me hopeful that it couldn't be retrieved! I figured the higher keyspace of a password would be beneficial. $\endgroup$
    – Goodies
    Aug 27 '18 at 4:14
  • $\begingroup$ Try to have a decive-unique tweak for the key (like incoperating a PUF into key derivation) and have some anti-tamper measures to make extracting this tweak hard. Also, limit the wrong pin attempts and delete the encryption key once a wrong pin has been entered x (maybe 10) times making the data unusable. $\endgroup$ Dec 26 '18 at 16:38
  • $\begingroup$ On 2: Fingerprints are unsuitable for the job because A) they are hard to keep secret. One keeps leaking its fingerprint to glasses, touch screens, keyboards, authorities. B) Fingerprints can't be easily changed. C) Fingerprints can't be the basis of a key without a training phase, meaning that a fingerprint-activated device failing with its training data is irreplaceable. $\endgroup$
    – fgrieu
    Aug 20 '19 at 6:21

I've decided to allow the user to choose between a pin code and a password.

 * Various authentication types are possible within SneakerPass.
 * For now, I've only implemented PIN (pin codes) and PWD (passwords). Here's how they work:
 * PIN:
 *    For a pin code, the user will enter a pin that can include only what is on the keypad.
 *    THIS HAS LOW SECURITY! On a 4x4 keypad with 0-9 and A-D, that's only 14 possible keys.
 *    You'd need a 20+ digit pin code to have the same security as a 9-character password.
 *    ONLY USE IF:
 *      1) You know the implications of using reduced-keyspaces pin codes
 *      2) You can quickly remove the SD card from the SneakerPass hardware (for destruction, ingestion, etc)
 *      3) You need the speed of a pin code and reduced security.
 *    Instructions:
 *      When the device is powered on, you will be asked to enter the pin code. Each key
 *      press will yield exactly one key. If you make a mistake, use '*' to erase the 
 *      previous value and re-enter it. When you're finished, press '#'. If it is correct,
 *      you will enter the SneakerPass menu.
 * PWD:
 *    This is the preferable solution. It definiely takes more time to enter a password
 *    like you're typing a text prior to the invenion of T9. However, the keyspace is greatly
 *    expanded to include uppercase/lowercase numbers, all 10 digits, and 14 symbols.
 *    Below describes what each character maps to. You must keep selecting the same key 
 *    to iterate through the values. If you are idle for 1 second, or if you select a 
 *    different key, that value will be submitted.
 *    KEY     NORMAL      SHIFT
 *    1       abc1        ABC!
 *    2       def2        DEF@
 *    3       ghi3        GHI#
 *    4       jkl4        JKL$
 *    5       mno5        MNO%
 *    6       pqr6        PQR^
 *    7       stu7        STU&
 *    8       vwx8        VWX*
 *    9       yz9         YZ(
 *    0       0-=         )_+
 *    A       []\         {}|
 *    B       ;'          :"
 *    C       ,./         <>?
 *    D       `           ~
 *    *       [ TOGGLE SHIFT ]
 *    #       [ SUBMIT/ENTER ]
  • $\begingroup$ I just realized, there's no backspace for the password mode. I'll figure something out. I think maybe # will be submit in normal mode, and backspace when shift is toggled. $\endgroup$
    – Goodies
    Aug 24 '18 at 22:29

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.