HMAC Authentication - how to secure private keys in flash?

[Bored@Work]

I am only allowed to use the cryptographic functions that will be NIST recommended secure till 2030+ for new products.

Well NIST. Yes. The US agency compromised by the NSA when it comes to security. Very clever to insist on NIST-recommended algorithms if you want to make sure the US has easy access.

[nctnico]

Actually the point of using broken or non-broken encryption should not be an issue. Good security builds on three pillars:
- Authentification
- Authorisation
- Accounting

For example: in the NL they used Mifare cards for the public transport where the account balance is kept on the card in a non-encrypted way. Since Mifare has been cracked it is extremely easy to increase the balance yourself. Or isn't it? The authentification and authorisation are clearly broken in this system but the accounting part (which keeps track on which card travels where) allows to pin point people trying to scam the system and arrest them.

[ovnr]

For example: in the NL they used Mifare cards for the public transport where the account balance is kept on the card in a non-encrypted way. Since Mifare has been cracked it is extremely easy to increase the balance yourself. Or isn't it? The authentification and authorisation are clearly broken in this system but the accounting part (which keeps track on which card travels where) allows to pin point people trying to scam the system and arrest them.

Reasonably easy to deal with: Devices that will fill up everyone's card by small amounts every time they're in range, placed at strategic points (close to the proper reader, etc - you can boost the NFC gain a bit). That way everyone's guilty all of a sudden. 

[mikerj]

Then please enlighten me what is your future security scenario with this device because you said that you could not protect the internal firmware?

I can't, at least not the degree required.  My understanding is that the Atmel device IS secure, holds the private keys and implements the HMAC.  All our device would need to do it pass the authentication message +key number from the host to the Atmel device, and then read the the message digest back and pass it to the host.  This means no secure comms are required between our micro and the Atmel device, and no storage of private is required within out micro.

Are you enlightened, or have I misunderstood the operation of the Atmel device?

Just for context, this security isn't going to have any significant consequences in the unlikely event that someone feels making the effort of breaking it which is why I think it's simply unnecessary (as does everyone working on the project).  As always however, the customer is always right, especially when they're wrong.

[Jeroen3]

Look at physical locks for example. You know, those in your doors.
They are classified in the number of minutes a skilled lock picker needs to pick the lock. Almost all locks can be picked, except those few that are very expensive.
And the weakest part of the lock system is people who lose their keys, or don't lock the door at all.

You need to find a balance in the security you need vs which you can afford.

[mikerj]

You need to find a balance in the security you need vs which you can afford.

We neither need, nor want this security on our device.  It's a potential customer being a pain in the ass.

[Kjelt]

In that case just do whatever meets the customer requirements and if it is usefull, if it is secure or not, so be it.

[marshallh]

Check out these to get some ideas. Without going into more crypto, the easy solution is to obfuscate the key as much as possible. You can also store up to 16 such keys in the external device and increment the key index in a new firmware update if a previous one was leaked

http://www.atmel.com/Images/doc8753.pdf
http://www.atmel.com/Images/doc8666.pdf