zimmerfrei

From #Rationale (concerning the backup option that most commercial HSMs allow):

>> I do am of the opinion that HSM's should not offer this option (getting access to the private key).

It boils down to your opinion then. Within the industry "HSM" is pretty much synonimous of compliance to FIPS 140, which allows key extraction even at its highest level (Level 4), provided that the risk is mitigated appropriately (E.g. by means of a split secret policy and more in general by means of all the security measures that go beyond the technologic ones provided by the HSM itself).

You are free to keep your opinion but the statement that such possibility "still beats the purpose of the HSM though" is not shared by many people.

Also (again concerning the backups):

>> Since it requires so many steps and so much access, I don't think this is a huge risk, but a rather nice convinience.

No, it is not a convenience. It is a manner to mitigate the risk of denial of service one may cause by purposedly destroying or stealing your HSM.

>> I've seen multiple big-name HSM's where their support was able to decrypt the key and transfer it to another HSM model, but since I've signed an NDA I cannot tell which ones that were.

I challenge this statement: I deal with most big-name HSMs (and there are not that many) and none of them can do this. I do know because that is a risk we explicitly check for when evaluating one.

In certain cases you may manipulate their API to extract some keys if they were generated internally in a certain way, but that is a known, public problem in the industry.

>> At least in my mind, the defining attribute of an HSM is protection against physical compromise of the device.

FIPS definitions help a bit here.

A hardware FIPS 140 Level 2 cryptographic module (HSM) is only required to show evidence of tampering. A $5 broken seal if often the solution. Note that applying a seal to the module in the link is not sufficient because I can compromise the thing without opening it (just press the button and reflash with non-signed images).

Level 3 is a step up in that you must have some degree of tamper resistance, but in several cases, most of this security behemoths just drop a layer of epoxy on the board and call it a day. Then they sell it to you for $10.000.

With Level 4 things get serious, but then you can count your suppliers in on hand and pay accordingly (and Safenet is not one of them).

I agree that smartcard-based solution would be ideal, but specs and native firmware and SDK are never open, so you cannot build an open-source product with them.

These hacks have actually been modeled and generalized into a mathematical construct called Mixed Boolean Arithmetic [1][2]. With a few matrix operations, you can actually generate an arbitrary number of hacky-looking (or obfuscated, as that was the actual intention of the authors of [1]) expressions from any initial, simple expression.

[1] http://link.springer.com/chapter/10.1007/978-3-540-77535-5_5 (and I deeply apologize I can't find the free PDF version, though sci-hub may help here)

[2] http://blog.quarkslab.com/what-theoretical-tools-are-needed-...

Around 100MB of physical RAM, to be shared among all enclaves active at a given time in the platform. Enclaves can be swapped out (if the OS/VMM is sophisticated enough), so in principle memory can be overbooked.

Granted that details are not there yet (but from previous work done by the author one can guess), would a formally proven OS like seL4 have prevented this? seL4 is somewhat weak on HW support but the functionality required in the secure domain doesn't do much I/O anyway.

Optimized ASM means code that only very few people are able to review, and only with considerable time and effort. If security is the primary concern, I would argue that optimized ASM becomes a liability.

Could you provide a reference?

>> - Use AES-GCM if you must use AES

Without CLMUL instructions, GCM is either very slow or potentially sensitive to cache-based side-channel attacks (regardless of AES being the underlying cipher).

The EAX mode of operation is more secure - though not very popular for some reasons and not part of any TLS cipher suite.

>> This kind of work is just as awesome as all the papers on CPU side-channel attacks (cache, branch prediction, etc) which really seemed to take off around 2005.

Maybe you meant late 90ies, when Kocher (and others) published results on side-channel attacks.

http://www.cryptography.com/public/pdf/TimingAttacks.pdf http://www.cryptography.com/public/pdf/DPA.pdf

RSA is actually one of the easiest algorithm to protect from side-channel attacks (though nothing gives you 100% protection), thanks to the various kinds of blindings you can immediately apply.

Blinding techniques are not constant-time, but what you really want in the end is to reduce the Signal-to-Noise ratio on the radiated energy.

For ECC it is more difficult, and it becomes very hard for most symmetric ciphers.

Honest question: what is wrong with tlslite? Why rewrite the same thing from scratch?

Tlslite is production-grade and it is written by someone with an actual, proven track in the security field.