How to make 'Password slots' work in a secure way?

[tuxlifan]

In firmware version 1.3.2 the new Password slots can be made to type out their (not so) 'secrets' by simply pressing the button in a defined and publicly known pattern; see #26.

To further develop this feature (which is a good idea in general to have, i.e. a way to access some password without a client) it seems necessary to devise a system to input a 'PIN' via key presses to unlock the password slot(s).

In any case there would be the need to guarantee that an attacker could not just upload a custom firmware and get to the (possibly separately encrypted) secrets. IIRC the bootloader can already force erasure of parts of the firmware storage on reflashing?

There are two main ways to authenticate the user that come to my mind right now: A) 'directly' via PIN B) via a scheme such as HOTP

The firmware has to (be able to) make a slot unusable after N wrong attempts, and an unusable slot could be made usable again only through the client program after unlocking the device with the regular master password. (e.g. firmware would save the increment counter before revealing the resulting status of an attempt and if the counter reaches the threshold overwrite the slot's secret (which would be backed up in the regular encrypted space to be restored through the client))

While with A) the secrets can be encrypted with the PIN as key and therefore not revealed even if someone found a way to dump the whole flash with B) all access is secured only by the firmware to compare things entered to something stored in more or less plaintext (unless there is hardware support?). Therefore I'll concentrate on A) below.

Example for A) After the user selecting the slot and long-pressing: 1) the Signet blinks or types out a character (e.g. +,* and = in rotation) at a rhythm 2) the user presses the button at certain points to enter the PIN 3) the Signet a) types the text if PIN is correct (erasing previous 'rhythm characters' first) b) flashes very rapidly for 2 seconds to signal 'wrong PIN' (so user can detect it after removing the finger from the button)

A major issue I see is that a button press is quite audible (which for regular operation is good to provide solid feedback when pressing the button).

If the secrets were not separately encrypted with a PIN this could be partially mitigated by allowing multiple PINs with codenames to be used. The Signet would then choose one, print the codename (or transmit it to the user via blinking pattern) and wait for user input. This could then be used as a very cumbersome but working OTP method (if the user regularly updates the PINs with the client after use) with the same basic drawback as B) discussed above so it might make more sense to go with B) right away.   Another way to mitigate the button clicks and keep separately encrypted PINs possible would be to vary the rhythm speed during input. This would of course not help against very determined attackers that record everything happening (i.e. audio+video+finger movement) but it would help somewhat against the 'colleague sitting on the other side of the monitor and hearing the clicking' especially when coupled with periods during the input sequence where the user could input any random clicks without them being included in the final PIN. Off course audio recording attacks over more than a single entry event would probably easily bypass that, too.   Or a challenge-response system where Signet prints 'random' characters and the user e.g. presses the button if 'a' is printed but not if there's a 'b' before it, etc.   Or a PIN within a PIN, jumbling parts of the PIN around (according to instructions given by the firmware, e.g. "Parts 4 3 2 1"), etc.   The complexity could increase endlessly until it's easier to just memorize that one password and enter it directly... :o

Of course there are still numerous questions to be asked and answered. Some of them:

• PIN entry:
  • how fast should the rhythm be?
  • my gut says about 0.5 seconds to have a short entry time, but this also leads to the next question
  • how exact does one have to be with the button presses?
  • Can we correlate a button press to e.g. a third of a pulse width? How to deal with human perception delay when changing the pulse speed dynamically? etc.
  • ... and the speed should anyway be user configurable to make sure the user can actually work with it!
  • Allow arbitrary lenght of input or a fixed length?
  • I think a fixed length would be easiest to process in a defined fashion
  • the user should be required to press the button (at any time while the rhythm is available) to start the sequence
  • the user should also be required to press the button on the last pulse to avoid giving away how short the real input sequence might be by looking away very soon.
  • rhythm: blinking vs. typing out characters
  • blinking is stealthier since it can be concealed as much as a user wishes by covering all or only part of the button with a finger/glove/etc. (unless the speed needs to be varied, see above...)
  • typing allows more flexibility to convey hidden signals to the user (frequency change, challenge-response sections, free-style, etc.)

And last but not least: if we come up with a good enough way to enter a PIN it should be possible to combine it also with the master password so that the unlocking with a client becomes a (password via computer/phone/...)+(PIN via device) combo.

What do you think?

[dumblob]

Please refer to the whole discussion in https://github.com/nthdimtech/signet-desktop-client/issues/22 and then feel free to close this issue.

[nthdimtech]

Agreed, lets discuss in one place