thats ultimately the intent, to build a Yubikey-like security key, with everything open down through the firmare to the details of the soc
These don't exist on embedded processors like the one I referenced.
And, if someone has physical access, all bets are off.
The only way to clear that bit is to erase the entire flash, with the notable exception of the user data section, so don't put the secret in there :).
Relevant recent discussion: https://news.ycombinator.com/item?id=17587673
8051 can read data from both CODE and XDATA memory spaces.
See: http://www.keil.com/support/man/docs/is51/is51_movc.htm
In the case of key loss on a properly secure service registering a new key could be problematical if you don't have any other key that is still appropriately registered - you might be permanently locked out unless there is an admin function who has a key registered so can do it for you.
Look at multi-key options for encrypted filesystem for one way that this can work. Often the filesystem or block device has a symmetric key that is in turn encrypted by each of the keys that you wish to be able to open it. It is the same symetric key every time, though you can't unlock my copy of it with your key nor can I unlock your's. Once unlocked we could both add a third user by encrypting the base key with their public key (PKI is not required, but is not uncommon).
Is there a standard to automate that ?
You may choose to have more than one key per person, to reduce the amount of re-registering needed if one key is lost, though remember that this is the second factor so you also already have passwords that vary by service (and if you give people multiple keys they will most likely carry them together to lose them all at the same time rather than individually anyway).
Like having several doors on your house, (though not a 'back door'..!) each with a different lock/key. _Not_ like having several locks on your one door, or multiple copies of the key for one lock.
However, other responses seem to be leaving out a discussion of why one would want to make identical keys in the first place. If you had identical keys, losing one would mean you'd need to revoke permissions of all copies. If the keys are instead unique, then only the lost key needs to be revoked.
Copying keys would also imply that the secret information needs to pass between devices, which adds some combination of risk and complexity. If the key doesn't need to support copying, then the secret information could be generated inside, and never leave, the key.
It seems better if the permissions granted to unique keys are easy to replicate, rather than the keys themselves.
But for traditional PKI schemes there's always at least one key (your personal master PGP key, your company SSH/X.509 CA) you want copies of, yet it's precisely the kind of key you absolutely want to keep off the network or within a secure hardware token; more so than authentication keys.
There are tokens that permit exporting (aka wrapping) a key for off-device storage or for transferring. If for transferring presumably you specify at key generation time a list of public keys to export to. But I've never used these tokens as the software was just too complex to bother with, proprietary, and poorly supported in the open source ecosystem. In the PGP world the typical advice (for better or worse) I've heard is to archive your master key on a disc and rotate your subkeys occasionally, necessitating brief exposure of your master key. Theoretically you would sign the subkeys from an old, non-networked computer.
Makes sense. And also it means I can decide it's not part of my threat model and take the easy route. Thanks.
(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.
Yes, I agree. But if you think about it, that can't be done by a device that does not have dedicated I/O, and two LEDs are not enough. At a minimum you need something capable of displaying a cryptographic hash if you want to protect against an pwned host.
I'm sure you are aware of Nitrokey. If not, here you go: https://www.nitrokey.com/
Edit: added link
What IP issues can you imagine happening considering ARM SoCs are the most widespread processors in existence with many, many different manufacturers?
Regarding side-channel attacks such as you mention, all processors are subject to this vulnerability to various degrees. Do not expect a project such as this to have any mitigation for that type of attack.