21–30 of 91 posts
Neat little device, looks like a Yubikey clone. One could get a similar device by hacking a Logitech unifying receiver, which contains a ..16MHz 8051 clone in it, and a radio to spare.
thats ultimately the intent, to build a Yubikey-like security key, with everything open down through the firmare to the details of the soc
(Disclosure: this is my project.)
I can recommend the DigiSpark as a cheaper, slower, alternative that works with the Arduino IDE [1]. Somebody could easily get it into a smaller form factor. I've bought some of the official versions in their KickStarter and whenever I buy through some company/research funding - but can also recommend the cheaper Chinese implementations to be just as good for projects. [1] http://digistump.com/products/1
Neat little device, looks like a Yubikey clone. One could get a similar device by hacking a Logitech unifying receiver, which contains a ..16MHz 8051 clone in it, and a radio to spare.
A Yubikey clone where you have to tap out a passcode (morse code style) might be neat.
I understand the security vs usability thing, just beware of the risks of something like this (perhaps bluetooth-type keys like this are more usable as you don't need to bother plugging them in, assuming bluetooth decides to play nicely)
Hold on - doesn't having this live permanently in the USB port reduce the security possible with a 2FA device? If the user has to get the key from their pocket and plug it in, it will at least prevent an attacker from accessing the user's account in a remote-desktop scenario. Certainly the requirement to press the button will mitigate this risk to a degree, but might there be exploits that can trigger this button-pre…
https://leaksource.files.wordpress.com/2013/12/nsa-ant-cotto...
Earlier quoted context omitted.
thats ultimately the intent, to build a Yubikey-like security key, with everything open down through the firmare to the details of the soc
You should check out: https://sc4.us/hsm/index.html (Disclosure: this is my project.)
>The SC4-HSM is designed to defend against a compromised client machine, i.e. an attacker who pwns your laptop or desktop machine. If you think about it, this is the only threat model that makes sense for dedicated secure hardware. If you can trust that your client machine is secure, you don't need an HSM.
From my prospective, that's the bare minimum threat model for an open secure hardware device. I also include unsupervised physical access to the device. My ideal HSM would also provide robust protections against a myriad of complex hardware-level attacks - JTAG debugging, power & RF analysis, glitching, de-encapsulation just to name a few.
Of course, a cheaper HSM which lacks advanced hardware level protections can still offer a lot of protection against common threat vectors, and physical access threats can be mitigated to some extent by keeping the device in a secure location or on your person.
Hold on - doesn't having this live permanently in the USB port reduce the security possible with a 2FA device? If the user has to get the key from their pocket and plug it in, it will at least prevent an attacker from accessing the user's account in a remote-desktop scenario. Certainly the requirement to press the button will mitigate this risk to a degree, but might there be exploits that can trigger this button-pre…
Earlier quoted context omitted.
GnuK ( http://www.fsij.org/doc-gnuk/ ) implements an OpenGPG Smart Card. Unfortunately, it targets STM32 chips with 128KB flash and 20KB DRAM, and the EFM32HG309 in the Tomu is only 64KB/8KB. I don't know how much work it would be to squeeze the code into the Tomu.
You should be able to use other chips in the EFM32 family as a drop in replacement, obviously requires soldering your own board. Seem to be available with up to 128K flash and 16K RAM. Of course the GnuK site lists some STM32 boards designed specifically to run GnuK. Or if you don't care about open hardware you can buy a $2 STLink clone on aliexpress and flash GnuK on it.
IIRC GnuK uses the chopstx library which has already been ported (see https://github.com/im-tomu/chopstx). Not sure what else would need to be done?
Earlier quoted context omitted.
thats ultimately the intent, to build a Yubikey-like security key, with everything open down through the firmare to the details of the soc
One key (pardon the pun) requirement of a 2FA key is that it can't be cloned - how would this be prevented? Can the microprocessor be locked to prevent reading its flash memory?
