Password storage on a BluePill

Guys.

I noticed this on HackaDay (it does not use a STM32)

https://hackaday.com/2017/11/30/mathieu … rd-keeper/

But I have been thinking for some time that as the BluePill normally has 128k of Flash, which can be marked as read protect, that it would be possible to build a password storage.

The device on Hackaday uses AES encryption (as I presume its storing the data on an external Flash chip (from what I can see on the schematic) or an external secure data card.

https://github.com/limpkin/mooltipass/b … ign_v1.pdf

I think something similar could be achieved on a BluePill, and I’m sure that the passwords could be encrypted with a passcode and stored in flash.

The flash could be set to read protect.

The weak link here seems to be the passcode, as if its only 4 digit and the flash got dumped, it would be game over.

So whatever firmware as run, it would need to be pretty robust to make it as hard as possible to extract the flash.

We already have code to act as USB HID and there is code (not for Arduino) to emulate a CH340 USB to Serial.

Anyway, just a thought….

a few things:

1) UID would be great: the password being stored / exchanged with the host / authenticator can be encrypted with the UID before it is stored on the chip. a lowly STM32 or STM8 can do that and be used to store practically limitless amount of passwords;

2) the key here will be figuring out a way to copy-protect the chip. STM32/8 aren’t the greatly here;

3) there are external devices, like rolling code chips or one-wire chips that can be used to enhance the copy protection;

4) a better medium is probably a phone: the sim card there is a great authenticator, as well as the finger print scanner. So if you can write a little app on the phone for authentication, it is a much better / cheaper approach than being marketed -> a true single sign-on.

[dannyf – Fri Dec 01, 2017 2:18 am] –

2) the key here will be figuring out a way to copy-protect the chip. STM32/8 aren’t the greatly here;

3) there are external devices, like rolling code chips or one-wire chips that can be used to enhance the copy protection;

I wasnt aware the STM’s read protection had been broken ??

The only device I know that there was a hack to read back was the Nordic nRF51 and they are phasing that out in preference for the nRF52 which does not have the same problem (which allowed code to be single stepped, and registers written to and read back in GDB in a read protected chip)

Re: 3

I guess it depends how secure it needs to be.

I have a password manager on my PC, but any malware could read the encrypted data, and any key logger could capture my login

So its not really that secure

The third party devices which don’t have easily accessible access to the data storage, and also where you have to enter the unlock code directly into the device would be more secure from those sorts of attacks.

Of course single password could be sniffed if they were sent in plain text via up the USB, but thats no different from a key logger for an individual website.

Having something which behaved like a HID keyboard which could send the passwords to whatever device it was connected to, would be rather handy, as I have soo many different devices, e.g. Android, iOS 6 , iOS9, Linux, Windows , OSX, that getting an offline pasword manager (software) that works across all of them and is not an online (hence unsecure) system, is impossible.

[RogerClark – Fri Dec 01, 2017 2:49 am] –

Having something which behaved like a HID keyboard which could send the passwords to whatever device it was connected to, would be rather handy, as I have soo many different devices, e.g. Android, iOS 6 , iOS9, Linux, Windows , OSX, that getting an offline pasword manager (software) that works across all of them and is not an online (hence unsecure) system, is impossible.

Maybe KeePass has ports for (quite!) all of them. But the idea of an hardware password manager is interesting!

https://keepass.info/download.html

[zoomx – Fri Dec 01, 2017 10:02 am] –

Maybe KeePass has ports for (quite!) all of them. But the idea of an hardware password manager is interesting!

https://keepass.info/download.html

Thanks

Quite possibly does support every device I use, but I’d still need to install it onto every device and keep the password file manually synced.

Ummmm.

I would likely implement one of the standards around public key (root certificate) and private key…. the ROM based password (s) would be signed with a private key.

mBed has a lib for tinySSL for ARM that could likely be compiled into the IDE code to decrypt the stored passwords:
https://tls.mbed.org/tiny-ssl-library

Ray

This is an interesting project. I think this other stm32f103 based project could have some relevant design/code: https://github.com/RaymiiOrg/gnuk/blob/master/README

Something to help make the brute force harder would be to use a brute force resistant hash like PBKDF2 as well as allowing a longer passphrase.

Thanks guys

@ddrown
The open source project you linked to was interested, but I don’t know if it’s the same sort of device I was thinking about.

It uses a H103,so I am not sure if the code would port over to the F103 for hardware and software reasons

Ray

Thanks for the link to that library

I think a strong passkey would be advantageous, because if the Flash was read back, it would not only reveal the data but also all the keys, and the firmware binary, so with a short passkey it would be easy to do a brute force attack, by simply running the firmware

The problem with a long passkey is how to enter it. The Mooltipass dongle has a rotary wheel with click, and I think you just enter 4 numbers, ( though it could be alpha numeric )

This seems like a neat solution, but perhaps a rotary encoder with the shaft sticking out the end, with a knob on it, would allow a alphanumeric passkey to be entered more quickly.

I did consider a small touch screen, but it would need a pen to tap on the size of small buttons that would be needed for a QWERTY keyboard

[RogerClark – Sun Dec 03, 2017 8:37 pm] –
Thanks guys

@ddrown
The open source project you linked to was interested, but I don’t know if it’s the same sort of device I was thinking about.

Yup, it’s not exactly the same. It stores PGP keys instead of passwords. But the storage of those secrets would be very similar, so those parts of the design and code could be used.

[RogerClark – Sun Dec 03, 2017 8:37 pm] –
It uses a H103,so I am not sure if the code would port over to the F103 for hardware and software reasons

They actually have a version for the blue pill as well as their official hardware.

[RogerClark – Sun Dec 03, 2017 8:37 pm] –
I think a strong passkey would be advantageous, because if the Flash was read back, it would not only reveal the data but also all the keys, and the firmware binary, so with a short passkey it would be easy to do a brute force attack, by simply running the firmware

The problem with a long passkey is how to enter it. The Mooltipass dongle has a rotary wheel with click, and I think you just enter 4 numbers, ( though it could be alpha numeric )

I was thinking about this. I was considering an arrow based interface to enter letters for a fixed word list. You’d have a fixed 4,000 different words to choose from, and passwords could be multiple words. Using a fixed word list could make it easier to enter and remember longer passwords.

so to enter the passphrase “convinces delay poem issuing”:

arrow down to “c” (26 choices), right arrow
arrow down to “o” (11 choices), right arrow
arrow down to “n” (12 choices), right arrow
arrow down to “v” (8 choices), right arrow
choose between (10 choices):
convenient, convention, conventional, conventions, conversation, convert, convince, convinced, convinces, convincing
right arrow

next word in the same way

The word list I have in mind is 4657 entries long, so 4 words out of it would be ln(4657^4)/ln(2) = 48.7 bits to brute force. Not impossible to brute force, but it would be expensive as long as the passphrase hashing system was designed properly. Using more words would make brute force harder, but would also make using it more annoying.

Using these numbers: https://gist.github.com/epixoip/a83d38f … 804a270c40

PBKDF2-HMAC-SHA256 9473.2 kH/s

That specific hardware is currently $21,000 (getting the GPUs alone would cost $4,000) and it would take on average 9 months (running 24/7) to crack one passphrase. More hardware would crack it faster in exchange for a larger up-front cost. Power usage would be roughly 2kwh/hr, or around $1400 for the 9 months (ignoring AC costs).

Edits: I’m hitting the wrong buttons

@ddrown

I like the idea of the passphrase made of a fixed set of words, but 4000 words is going to take a lot of flash.

Re: Cost of GPU rigs to brute for etc

Ultimately everything is hackable, with enough budget the top can be etched off the MCU and the flash read back via direct connections, I’ve heard there are companies in some countries who will do this for you if you have enough money

But I’d be more concerned with a buffer overflow code injection being possible which could potentially dump the flash.

[RogerClark – Mon Dec 04, 2017 2:18 am] –
@ddrown

I like the idea of the passphrase made of a fixed set of words, but 4000 words is going to take a lot of flash.

Yeah, around 35kb. I could possibly lower that (12kb?) if I stored it as a tree structure.

[RogerClark – Mon Dec 04, 2017 2:18 am] –
Re: Cost of GPU rigs to brute for etc

Ultimately everything is hackable, with enough budget the top can be etched off the MCU and the flash read back via direct connections, I’ve heard there are companies in some countries who will do this for you if you have enough money

But I’d be more concerned with a buffer overflow code injection being possible which could potentially dump the flash.

Glitching (via power/clocks/etc) is another way to possibly dump the flash.

Yep.

There are loads of ways to potentially get the MCU to misbehave.

BTW. I found this doc

http://www.emcu.it/SILICA-STDay-2016/X/ … ements.pdf

But, I’m not sure why the F1 often has a asterisk against it

[ddrown – Mon Dec 04, 2017 2:32 am] –

[RogerClark – Mon Dec 04, 2017 2:18 am] –
@ddrown

I like the idea of the passphrase made of a fixed set of words, but 4000 words is going to take a lot of flash.

Yeah, around 35kb. I could possibly lower that (12kb?) if I stored it as a tree structure.

Combining https://en.wikipedia.org/wiki/Incremental_encoding and a 127 element dictionary for the suffixes, I get:

wordlist.o :
section size addr
.text 0 0
.data 0 0
.bss 0 0
.rodata 18856 0
.comment 45 0
.note.GNU-stack 0 0
Total 18901


Thats interesting encoding / compression

I agree, Unicode is not required as it doubles the data size (assuming 16 bit)

I don’t think accented chars are needed, probably most latin style languages could be catered for using ASCII

I just had another idea for passkey input

I noticed a post about these gesture detectors , APDS-9960

Sparkfun did a video

https://www.youtube.com/watch?v=A3QRyixnEl8

This really cheap devices, seem to have multiple time of flight sensors (or something else that can sense distance), and can be used to sense direction of swipe and other gestures

Potentially a passkey could be a sequence of movements that has to be made by your hand over the device.

Of course if someone was filming or observing you, they may be able to duplicate the gesture, but its an interesting alternative, and would mean they would have to video you doing the gesture (no pun intended)

Gesture detectors are interesting too.
You have to take care of the detecting accuracy otherwise other similar gestures can pass the check.

[zoomx – Mon Dec 04, 2017 8:54 am] –
Gesture detectors are interesting too.
You have to take care of the detecting accuracy otherwise other similar gestures can pass the check.

Yes.

You have to decide on the accuracy.

I have some experience developing a 2D gesture system, but its fairly simplistic, as it just divides the required gesture into a series of short lines P1 (x1,y1) -> P2 (x2,y2) then calculates minimum distance from the entered co-ordinate (the mouse position) to the line and checks its not beyond a threshold, it also checks that the nearest point on the line is always increasing i.e they are moving from P1 to P2

We don’t track speed of movement in the gesture as it was not a requirement. i.e only that the gesture was performed in the correct direction(s)

We also didn’t allow for different scale, though we could do this if we processed the whole gesture when it was complete – but as we needed to do realtime checking, it was impractical to try to determine scale on the fly

So… Yes its difficult to do it well .

off-topic but i googled and run across this article about attacking trezor a hardware wallet for securely storing Bitcoins
https://jochen-hoenicke.de/trezor-power-analysis/
my guess is stm32 may be made to pretty much work like or as a trezor clone, the vulnerabilities are likely similiar
it is rather interesting/impressive that the attack is done by doing reverse engineering from the power consumption and using an oscilloscope. without literally breaking the read protection h/w etc

Thats a very interesting article

Unfortunately, it seems to show that open source code will be inherently less secure as reference code can be run, and the power usage compared.

But ultimately, pretty much anythng can be hacked if you have enough time and money

Unfortunately, it seems to show that open source code will be inherently less secure as reference code can be run, and the power usage compared.

Roger, I think you are being too pessimistic! That argument smacks too much of Security Through Obscurity to me. I believe some of the most secure implementations are indeed open sourced.

The above link is a Simple Power Analysis and for that the source code is likely to be a help. More sophisticated attacks like Differential Power Analysis perform statistical analysis and hypothesis testing to determine the cryptographic keys.
In one case of our testing, we were able to determine a DES key because some of the S-Box tables spanned the page boundary of flash memory. This resulted in a power consumption difference that was enough to break the implementation!
The bottom line is to leave secure crypto implementations to the experts! Of course, even a weak implementation is better than nothing — but don’t be over confident of your security.

If your are interested in this sort of thing, I recommend looking at the Chip Whisperer project by Colin O’Flynn

Finally, for weaknesses in the STM32F0 it is worth reading Shedding too much Light on a Microcontroller’s Firmware Protection.
They basically use a race condition on the STM32F0 to readout the firmware. Due to hardware differences I don’t believe this works on the STM32F103 chips.

Eric

Thanks Eric

To be honest, I was not looking for ultimate security, just something that was good enough for me to use personally.

I agree crypto etc is best left to the experts, and even then , a few years later someone finds problems with it

I reduced my word list to smaller words and now it’s 1194 words and 3831 bytes compressed.

I wanted to see how long it would take to enter these words into a simple interface, so I created a javascript prototype version: https://dan.drown.org/misc/password-entry.html

It only works with a keyboard, so trying it on mobile devices is no good.

Some example entry:

you typed: usage rules led hack heh with 92 keypresses taking 47.723 seconds
you typed: able to have fun with 75 keypresses taking 25.585 seconds

Entering random 5 word (~51 bit) passphrases took 90~100 keypresses and 40~60 seconds

Let me know what y’all think of this interface.

Its a cool interface, but I found I could not enter the passphrase I wanted

I thought I’d try the old joke

Time flies like an arrow; fruit flies like a banana

https://en.wikipedia.org/wiki/Time_flie … e_a_banana

And I couldn’t enter it as it didn’t have fruit or arrow

It was a bit slow to enter the text using the keyboard , but a rotary input of some kind would be quicker

BTW. I did look to see if there were small LCD or OLED screens with Touch screen, but I couldnt see any, so rotary input looks like its the best

[RogerClark – Wed Dec 06, 2017 2:17 am] –
Its a cool interface, but I found I could not enter the passphrase I wanted

I thought I’d try the old joke

Time flies like an arrow; fruit flies like a banana

https://en.wikipedia.org/wiki/Time_flie … e_a_banana

And I couldn’t enter it as it didn’t have fruit or arrow

It was a bit slow to enter the text using the keyboard , but a rotary input of some kind would be quicker

BTW. I did look to see if there were small LCD or OLED screens with Touch screen, but I couldnt see any, so rotary input looks like its the best

Yeah, I could change the interface to allow any word. That would make it more flexible and use less flash. The downside would be it would increase the number of keypresses/rotations to get the proper word in.

Or perhaps add more words

Probably allocating 8k or at most 16k for the password storage should be enough,

Anyone who has loads of very long passwords, probably needs to use something else

Part of computer security is estimating how much money an attacker has to spend to gain access. If the attack takes less than $0.01 per target (such as: injecting malware via browser exploit through an ad network, scanning for devices with default username/passwords open to the internet, etc) you can bet it is being done in a wide scale way.

If the attack takes a few dollars, such as something that takes a human’s attention per target over the internet, that still happens plenty but is less common relative to the cheaper things.

And so on. I’m happy to see that most of the attacks listed here require physical access, because that raises the cost and lowers the opportunity. Attacks don’t need to be impossible, just not worth it economically.

[RogerClark – Wed Dec 06, 2017 3:44 am] –
Or perhaps add more words

Probably allocating 8k or at most 16k for the password storage should be enough,

Anyone who has loads of very long passwords, probably needs to use something else

Ok, I put in a larger wordlist on the web page – from 1,194 to 2,741 words. The object file for this wordlist is 9066 bytes

Wow… 1k is really small.

I’ll give it another try

If one is just making a device for oneself, it seems to me that one can do quite well with security through obscurity. The first level of obscurity is that one can make the device look like it’s something other than a password storage device. Then one can implement things in a completely nonstandard way in the software, say running the encryption algorithm in a custom interpreted language that isn’t used anywhere else, varying the algorithm from a standard algorithm (even if that adds some crypto weakness). A persistent enough hacker can figure it out, but unless one is very special (a public figure, a spy, etc.), it’s unlikely an enormous effort would be put into cracking a one-off personal device, breaking a one-off custom encryption algorithm.
Of course, maybe this project is meant for a larger audience, in which case everything I said is off base.

It was a bit slow to enter the text using the keyboard , but a rotary input of some kind would be quicker

If there was resources left-over in the application, a Morse Code decode could be implemented … it is rather low resource intensive especially if the LCD display is eliminated. I’ve implemented it even on a PICAXE 08M2 in BASIC.

There are multiple algorithms: I prefer mine, here or here.

The implementation would be really small if mapped to numeric only!

Ray

Ray

Morse code input did cross my mine, as it’s something I can personally send and receive; though I am a bit rusty and suspect I could only receive at perhaps 5 words one minute.

Originally to get my ham radio license I had to send and receive at 12 words per minute, but that was many years ago

A trimpot with say 5-8 positions marked, simply rotate in a code, like with the famous knobs on a safe. Read the voltages, wait a second (or a specific time) at particular position and when the sequence and timing matches, it opens your safe
Or, take an accel/gyro module an rotate your safe in a specific sequence. Add a microphone – whistle in a sequence. Or combine all above

@pito

We seem to be heading back to what Mooltipass does, which is a 4 digit pin code entered via a thumb wheel

But I like the idea of a more traditional combination lock.

kinda retro

A few 1% resistors, a multi-detent wafer rotary switch, 1 AD port, one pushbutton (optional) because either end-position of the rotary switch could act as the “enter” sequence.

Of course, NFC from your cellphone.

And new, the NFC ring:

I put together a stm32duino example of the wordlist: https://github.com/ddrown/wordlist

Full example with display uses 33KB of flash, so that’s not much room for encryption or other things. I can probably cut a bunch of un-needed stuff out of the graphics libraries though.

I was thinking maybe it would be best to store the passwords encrypted on an external SD card. That would make backups easier. It would make having a good encryption password more important.

The reason I’m exploring the word list as a way to enter the passphrase is I think it makes complex passwords easier to remember. See: https://xkcd.com/936/ and https://en.wikipedia.org/wiki/Diceware

I think we can assume that the BluePill has 128k for the purposes of this.

Or people could use a Maple mini which is guaranteed to have 128k