Embedded password security enhancement in keyboard

[metalliqaz]

All modern PC keyboards, even the feature-packed, fully-programmable customs that we have now, are transparent.  By "transparent" I mean that the user presses a key or key combination and the PC receives the single input that is expected by the user.  In other words: the user thinks it, the PC gets it.  Embedded macros stretch this definition but the property still holds because the PC gets the phrase the user wants to send.  (Lets not get into Caps/Num/Scroll lock right now)

This is a wonderful property of keyboards and probably explains why we like them so much.  The tactility of the keys are the only feedback needed for complete immersion.  Mice don't have as much of this property because you have to look at the screen to see the effect your actions have on the cursor.  However, I digress.

I am currently working on a new feature for my own keyboard that will bend this property even more than macros.  I'm adding a new function that convolutes key presses for the purpose of entering more secure passwords.  Essentially I am embedding a hash function that appears random to the user but is actually deterministic.  It's an embedded password generator.  A secret string is stored to the keyboard, and a second string is remembered by the user.  They are then combined and hashed to result in the actual passphrase.

So, I may choose "my secret convolution phrase!" to be stored in the keyboard's flash, and remember my password as "123456" and when I type "123456" the keyboard outputs the result

"my secret convolution phrase!" # "123456" = "3?DF$^gfdQ#$6F_SD5FsG"

This is NOT encryption.  A particularly brutal security researcher may actually call this  security by obscurity.  However, I suggest that this is significantly better than what most users use.  I am trying to protect against compromised service providers, not from local threats.  It gives you a password that is essentially impossible to bruteforce from something easy to remember like "123456".  Even nicer is that to change a password, you can change either the string you remember or the secret string.  Whichever suits your needs!  It is obviously best to pack as much entropy into the secret string as possible.


It currently works like this:

* Press the "convolution" key to put the keyboard into password mode
* Type the password.  No scancodes are sent to the PC while the user types
* Press Enter or Tab
* The keyboard computes the actual passphrase using the entered keys combined with the stored secret
* The keyboard stores the result in the RAM macro buffer and sends it
* Keyboard goes back to normal mode

The keyboard can store more than one configuration.  Each configuration comprises (1) a secret, (2) settings for which characters should end up in the final passphrase (uppers, lowers, numbers, symbols), and (3) how long the final passphrase should be.

Pros:
* powerful passwords from easy to remember strings
* change passwords by changing either the stored or remembered secret

Cons:
* can't see your characters when you type, however this is often the case with passwords anyway
* extra keypresses to slow you down


Alright everyone, what do you think of this?  Have you heard of anything like this before?  Do you think it would help you be more secure online?  Do you think it would be too annoying to use?  Do you want to try it yourself?  I'm not sure if I want to make the algorithm public, but if you have a Phantom, you'll probably be able to try a prototype soon.

[mkawa]

there are a bunch of research papers in this area. it's been a long time since i've looked at this area, but i will get you some pointers.

the other way to look at this is that you're embedding a 1passwd like database into the keyboard MCU.

a couple things to note about this: the MCU needs to be hardened against attacks from the computer. for example, the password database should be private key encrypted.

you also still need to protect against MITM (or more appropriately, man on the bus) attacks. eventually, the scancodes for the password have to be sent on the serial bus, and they can be snooped at that point. i would suggest that instead of making it implemented solely in hardware, write a driver that handshakes with the keyboard when sending passwords across, so that you can get privacy and authenticity on the bus. this is nice because it means that an attacker has to root the machine in addition to the board in order to get at the protected data

a mistake that a lot of people make when implementing security protocols is misappropriating security properties of different mechanisms. authentication methods, such as signing, _only provide authentication_. encryption mechanisms only provide secrecy over short finite periods. hash functions only provide qualified one-wayness.

so for example, let's say you're running long-lived ssl sessions and there is an adversary snooping somewhere between your daemon and your users. ssl gives much weaker security properties over long-lived sessions than short sessions due to a lack of forward-secrecy by default. because of this, every packet observed by the adversary increases the probability of the adversary being able to break into the session in a number of ways.

[RabRhee]

Apart from the technical aspects Mkawa brings up, I think there are more downsides that make it less than perfect for many situations. Plus I am not canvinced brute force methods are the biggest threat to passwords compared to, say, fake sites or keyloggers. This seems like an option to be lazy, ie. have simple passwords that come out complex, rather than doing the work and creating complex passwords in the first place.

Other pros.
it thwarts someone looking over your shoulder to learn your pass, unless they use your machine to enter what they see.

Cons.
If you need to use your password on more than one device.
If your keyboard fails, you need to reset every password that uses this method because you don't really know your own passwords. This also requires you to leave at least one password recovery method outside this loop.

The concept of a keyboard command that interfaces to a driver sounds more powerful, a more technical version of entry via mouse or cut/paste, something that is harder for a rogue element to record.

[metalliqaz]

there are a bunch of research papers in this area. it's been a long time since i've looked at this area, but i will get you some pointers.

the other way to look at this is that you're embedding a 1passwd like database into the keyboard MCU.

a couple things to note about this: the MCU needs to be hardened against attacks from the computer. for example, the password database should be private key encrypted.

you also still need to protect against MITM (or more appropriately, man on the bus) attacks. eventually, the scancodes for the password have to be sent on the serial bus, and they can be snooped at that point. i would suggest that instead of making it implemented solely in hardware, write a driver that handshakes with the keyboard when sending passwords across, so that you can get privacy and authenticity on the bus. this is nice because it means that an attacker has to root the machine in addition to the board in order to get at the protected data

a mistake that a lot of people make when implementing security protocols is misappropriating security properties of different mechanisms. authentication methods, such as signing, _only provide authentication_. encryption mechanisms only provide secrecy over short finite periods. hash functions only provide qualified one-wayness.

so for example, let's say you're running long-lived ssl sessions and there is an adversary snooping somewhere between your daemon and your users. ssl gives much weaker security properties over long-lived sessions than short sessions due to a lack of forward-secrecy by default. because of this, every packet observed by the adversary increases the probability of the adversary being able to break into the session in a number of ways.

Wow, all cool stuff.  Thanks!

Most of it goes way past what I'm proposing.  I've seen some the research on local intercepts and of course I'm familiar with MITM, but I'm not proposing any solution to those issues.  Like I said I'm trying to protect against compromises at the service provider.  For example, Dropbox has its user database hacked and stolen.  I'm not proposing this as any real increase in local security.

Really what it comes down to is the memory vs. strength dilemma.  Good passwords are hard to remember.  Easy to remember passwords can be brute-forced in seconds or minutes.  I want to have the best of both worlds.  I want to go to Dropbox and only have to remember "dropbox" as my password, but have it come out as 25 characters of gobbledygook. (yes I googled how to spell that)

[metalliqaz]

Apart from the technical aspects Mkawa brings up, I think there are more downsides that make it less than perfect for many situations. Plus I am not canvinced brute force methods are the biggest threat to passwords compared to, say, fake sites or keyloggers. This seems like an option to be lazy, ie. have simple passwords that come out complex, rather than doing the work and creating complex passwords in the first place.

Other pros.
it thwarts someone looking over your shoulder to learn your pass, unless they use your machine to enter what they see.

Cons.
If you need to use your password on more than one device.
If your keyboard fails, you need to reset every password that uses this method because you don't really know your own passwords. This also requires you to leave at least one password recovery method outside this loop.

The concept of a keyboard command that interfaces to a driver sounds more powerful, a more technical version of entry via mouse or cut/paste, something that is harder for a rogue element to record.

More good points.  I shall think on these things.  In my view the killer downside is the inconvenience away from my keyboard.  Don't know if I can overcome that.

I'd just like to disagree with your first point.  I think the high-profile compromises over the past year (Target, et al.) show that we can't trust companies with our passwords anymore.  Phishing is probably the number one threat and I think I can protect myself fairly well from that.  Then I'd put cracking compromised databases as a biggie.

I was already planning on having a desktop and Android version of the algorithm, if I decided to actually implement this method.

[RabRhee]

... Then I'd put cracking compromised databases as a biggie.

True, this is becoming a bigger problem as time goes on and computing power increases. I think that is also why many sites have increased minimum password length from 6 to 8, and forcing numbers and symbols. pushing a dictionary through a one-way system isn't the chore it used to be

I guess I tend to deal with non-techy people, and their passwords are always compromised by the old fashioned tricks. Organised crime is becoming very technical, database thefts are on the increase.

[mkawa]

a friend of mine points out that your system maps the same keyboard-entered password into the same hashed password, which is generally a big no-no for password generation techniques.

one-wayness is also parameterized on how many i/o samples the adversary has access to. if you are only using a OWF to obscure passwords, you are bound by that qualifier.

[mkawa]

one last nitpick is that convolution is a signals and systems thing that means something specific that is not this

[metalliqaz]

a friend of mine points out that your system maps the same keyboard-entered password into the same hashed password, which is generally a big no-no for password generation techniques.

The real password is not what you enter on the keyboard.  It's what you save in flash.  That one should be strong, perhaps 32 bytes from random.org.  The system just requires you to type something so that a person who uses your keyboard can't press a button and have your password come out.

one-wayness is also parameterized on how many i/o samples the adversary has access to. if you are only using a OWF to obscure passwords, you are bound by that qualifier.

I alluded to this when I mentioned security by obscurity.  I think it's plenty good enough for me.  Not good enough to offer as a product, though.

[metalliqaz]

one last nitpick is that convolution is a signals and systems thing that means something specific that is not this

I'm sure you're right, but...

con·vo·lut·ed
adjective
1.  twisted; coiled.
2.  complicated; intricately involved: a convoluted way of describing a simple device.

close enuf  )

[BlueBär]

Hmm, I'm not seeing any real advantage here. What you're doing is somewhat a hardware password generator. This would only make you safer against brute force attacks (or against people who watch you) with the downside of having to take your keyboard with you as a sort of oversized key. A standard soft- or hardware keylogger would be enough to "break" your system.

[eviltobz]

all the naysayers have perfectly valid points about the extent of the security that you're proposing, but i think it sounds pretty damn cool and as you say, it's not trying to solve those problems. yeah, it won't stop a keylogger, but then, nor will typing in a good password manually having a little android app so you can work out your passwords when you're away from your board also sounds handy.

having the password for each site you use being the name of the site becomes nice & easy to remember, and with the hashing approach, the value that each site sees has no relationship to another site's password created the same way. unlike, say, the technique of having a standard bit of password that you always use & some mnemonic for the site that you wap together, whereby once you've found it in one password database you could start to guess it in others. not that i've been guilty of using such password creation techniques in the past

hmmm, i don't have a phantom, so i'll not be trying out your version, but mebe i'll think about doing something similar with some ergodox firmware at some point. not til i get my second one made though, so i have one at home and one at work

[agodinhost]

... the other way to look at this is that you're embedding a 1passwd like database into the keyboard MCU.

You would have to change the bootloader too - otherwise anyone would be able to overwrite your code and throw away your pass protection ....

[mkawa]

AVR lockbits prevent everything short of high voltage RST programming.