Live data from Hacker News

Why I don't like smartcards, HSMs, YubiKeys, etc.

devever.net

111–120 of 139 posts

Re: Why I don't like smartcards, HSMs, YubiKeys, etc.

#111
post #91
post #71

This site is down so I was not able to read the original article, but I would like to take this opportunity to draw HN's attention to my current project: https://sc4.us/hsm It's a fully open USB HSM based on an STM32F405 SoC. Includes an HWRNG, 1MB Flash, and 196k of RAM. Currently runs TweetNaCl and also functions as a FIDO U2F token. Technical details are here: https://sc4.us/hsm/manual.html Currently out of stock…

I'm interested in buying a couple of these. Howver I'm wondering if there's a way I can also use it as a TOTP to replace my Google Authenticator app for several accounts? I don't really like having it in the phone because when I lose it I need to reset everything and it's a pain. Is it possible with SC4 to achieve this functionality?

Also... why do you want TOTP rather than U2F? U2F is better in every way (unless you don't have access to a USB port).

Re: Why I don't like smartcards, HSMs, YubiKeys, etc.

#112
post #16

Odd -- JavaCard smartcards are available for under $5, have crypto co-processors, and certainly support general-purpose code. See for example my project for KeePass, http://code.lardcave.net/2016/08/06/1/ . After programming, you can choose to lock down the card (which means you can only erase the card, not modify it). I'm using NXP chips and although I haven't investigated completely I would be highly surprised if i…

I tried to do something like this last summer. I found little to zero intersection between the cards that GlobalPlatformPro can personalize, and the cards that you can just buy in low volume at reasonable cost. I think I did buy one "$5" JavaCard but the shipping was like $50. As much as I admire GlobalPlatformPro, staking your small company's security infrastructure on 1) a hobby project maintained by one guy (Marti…

this "one guy" here. I would say that the availability of open access cards is almost excellent these days, at least in EU. The quality of those easily available cards (chinese) is questionable though. But there are cards available from other vendors as well (most notably NXP)

Re: Why I don't like smartcards, HSMs, YubiKeys, etc.

#113
post #99
post #35

Earlier quoted context omitted.

Both Smart Cards and HSMs can (and frequently do) contain FIPS validated cryptographic modules and can be USB devices. What seems to set them apart is content capacity and speed. A "HSM" can usually store dozens, hundreds, or even tens of thousands of keys and can do numerous cryptographic operations per second. Most "smart cards" can only store a few keys and frequently 1-2 operations per second. Many HSMs also add…

>Many HSMs also add advanced authentication capabilities, such as M-of-N access control And this is exactly my point, it's all functionality which the manufacturers have decided some customer might need. I don't want that, I want a secure general-purpose Turing-complete execution environment which gives me full flexibility in what crypto, mechanisms and policy to implement. This entire industry approach is silly.

Any old server gives you full flexibility. One key point is, what do you mean by secure? If they give this Turing-complete machine to their customers, and then the customer uses or is given the wrong software (Murphy's Law), how is it going to be assured that this is still "secure"? And are many other paying customers looking for this Turing-complete thing they can write their own software for, or don't a lot more customers want turnkey solutions to specific problems?

Re: Why I don't like smartcards, HSMs, YubiKeys, etc.

#114
post #111
post #91

Earlier quoted context omitted.

I'm interested in buying a couple of these. Howver I'm wondering if there's a way I can also use it as a TOTP to replace my Google Authenticator app for several accounts? I don't really like having it in the phone because when I lose it I need to reset everything and it's a pain. Is it possible with SC4 to achieve this functionality?

Also... why do you want TOTP rather than U2F? U2F is better in every way (unless you don't have access to a USB port).

Many more services implement TOTP and not U2F, so this would tend to be seen as a useful thing for end users even if the technology is unattractive.

Re: Why I don't like smartcards, HSMs, YubiKeys, etc.

#115

Earlier quoted context omitted.

I tried to do something like this last summer. I found little to zero intersection between the cards that GlobalPlatformPro can personalize, and the cards that you can just buy in low volume at reasonable cost. I think I did buy one "$5" JavaCard but the shipping was like $50. As much as I admire GlobalPlatformPro, staking your small company's security infrastructure on 1) a hobby project maintained by one guy (Marti…

this "one guy" here. I would say that the availability of open access cards is almost excellent these days, at least in EU. The quality of those easily available cards (chinese) is questionable though. But there are cards available from other vendors as well (most notably NXP)

Haha I love HN.

EU might be the differentiator. I do remember seeing a lot of cards that would only ship to EU, or shipping to US was prohibitively expensive.

Keep up the awesome work.

Re: Why I don't like smartcards, HSMs, YubiKeys, etc.

#116
For the microchip itself, I'm pretty sure this already exists.

Try looking at nRF52. It has NFC, Bluetooth radio, and hardware RNG. I'm pretty sure it has the features he asks for (firmware can lock down and block reading/writing from debug port. but debug can always do a complete erase/reset of the chip)

A future SKU will probably have USB as well.

The only problem is it is probably too power hungry to be powered by the NFC radio waves itself. And that is probably true for anything with an powerful ARM microcontroller.

Maybe it'd be best to use a microcontroller with ARM TrustZone as well though. That should help bring the security of the device up to a more acceptable level.

Re: Why I don't like smartcards, HSMs, YubiKeys, etc.

#117
post #114
post #111

Earlier quoted context omitted.

Also... why do you want TOTP rather than U2F? U2F is better in every way (unless you don't have access to a USB port).

Many more services implement TOTP and not U2F, so this would tend to be seen as a useful thing for end users even if the technology is unattractive.

Actually, I just thought of a way you could make this work with a terminal command instead of a driver. You'd have to type something like:

date > /dev/cu.usbmodem*

and the OTP would appear on the HSM display. Would that work for you?

Re: Why I don't like smartcards, HSMs, YubiKeys, etc.

#118
post #21
post #16

Odd -- JavaCard smartcards are available for under $5, have crypto co-processors, and certainly support general-purpose code. See for example my project for KeePass, http://code.lardcave.net/2016/08/06/1/ . After programming, you can choose to lock down the card (which means you can only erase the card, not modify it). I'm using NXP chips and although I haven't investigated completely I would be highly surprised if i…

I even have a ring that runs JavaCard software on its JVM, they are sold for cheap, and I bought one just for fun and history, there is an eBay listing here: http://www.ebay.co.uk/itm/JAVA-RING-RARE-Sun-Microsystems-JA...

That seems like a great way to distribute some secret. Create an Arduino reader for the ring, save the secret in a format that requires 3 out of 5 rings to reconstruct and store them apart.

Only the most persistent and knowledgeable about the ring will go through the trouble to get the data off it.

Re: Why I don't like smartcards, HSMs, YubiKeys, etc.

#120
post #113
post #99

Earlier quoted context omitted.

>Many HSMs also add advanced authentication capabilities, such as M-of-N access control And this is exactly my point, it's all functionality which the manufacturers have decided some customer might need. I don't want that, I want a secure general-purpose Turing-complete execution environment which gives me full flexibility in what crypto, mechanisms and policy to implement. This entire industry approach is silly.

Any old server gives you full flexibility. One key point is, what do you mean by secure? If they give this Turing-complete machine to their customers, and then the customer uses or is given the wrong software (Murphy's Law), how is it going to be assured that this is still "secure"? And are many other paying customers looking for this Turing-complete thing they can write their own software for, or don't a lot more cu…

While these devices are turing complete machines under the hood, the interface to them is incredibly strict.

Using them from code is like using a remote API, you can't execute code, you can only make requests and receive responses, and a lot of thought it put into the interface to ensure it's as secure as possible.

As far as the physical interface, they are more like an appliance than a server, in that you don't get the normal ports you would on any other machine, the actual casing is typically alarmed so that keys are wiped when the device is opened, important circuitry is embedded in epoxy so that it's essentially impossible to attach debugging instruments without destroying it, etc.

I can't really emphasise enough how these machines are designed for security.

Post reply on HN