Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devever.net

Post reply on HN
Print view View original

91–100 of 139 posts

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

#91

Post by saganus »

lisper wrote: 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?

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

#92

Post by userbinator »

konstmonst wrote: post #66
kosma wrote: post #62

Earlier quoted context omitted.

Send me a locked STM32F1 chip and I'll send you back the binary contained in it. Not kidding. The problem with general purpose MCUs is that they are trivial to break.

I would be very interested in the information on how can you do this :) We already use a Cypress PSoC5LP MCU with a flash protection feature as a License Manager(Essentially a TPM with encyption keys in locked flash) because we had a surplus of those. I am just trying to estimate if it is dangerous an should be changed. Our case is to prohibit Customers (mostly industry) from pirating firmware for new devices.

Various companies in China and Russia will read locked MCUs for a fee. Search for "MCU Break".

I know someone who uses one of these services to get the firmware for old industrial equipment whose manufacturer had long gone out of business or stopped providing support and replacing would cost far more. Total cost was <$1000USD, although that was an older MCU.

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

#93

Post by kosma »

lisper wrote: post #85
kosma wrote: post #83

Earlier quoted context omitted.

Security on F4 is way better. I haven't found a way to circumvent the JTAG fuse - but to be honest, I never really tried as I don't have access to proper glitching hardware.

What would you need?

A ChipWhisperer and some boring winter weekends, probably. I don't break these for cash or fame; it's just for fun.

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

#94

Post by Cyph0n »

ci5er wrote: post #89
Cyph0n wrote: post #7

The issue of affordable HSM/TPM for general purpose use is something my research group is trying to solve. We have most of the theory down, but the implementation is a work in progress. The key point is trying to maintain full physical isolation from the CPU and OS, while also providing general low-level computing capabilities. Do you guys think something like this could be patented and/or commercialized?

IBM's Citadel project and Doug Tygar's group at CMU researched crypto co-processors about 20 years ago. You can still find Bennet Yee's PhD thesis online. It and it's bibliographical references gave a pretty good overview of the lay-of-the-land at that time. You'd think that the theory might have progressed some since then, but theory doesn't progress as fast as a front-end development framework... Bad memories of ho…

I read through Tygar and Yee's paper on secure boot during my research. Their work was very good to be frank. They foresaw most of the recent developments in TPM design, which I thought was quite impressive.

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

#95

Post by ci5er »

Cyph0n wrote: post #94
ci5er wrote: post #89

Earlier quoted context omitted.

IBM's Citadel project and Doug Tygar's group at CMU researched crypto co-processors about 20 years ago. You can still find Bennet Yee's PhD thesis online. It and it's bibliographical references gave a pretty good overview of the lay-of-the-land at that time. You'd think that the theory might have progressed some since then, but theory doesn't progress as fast as a front-end development framework... Bad memories of ho…

I read through Tygar and Yee's paper on secure boot during my research. Their work was very good to be frank. They foresaw most of the recent developments in TPM design, which I thought was quite impressive.

Oh - cool. It wasn't clear to me from your top-level comment how far back you'd gone. Even though it's old, I still think it's pretty good, and thought you should be made aware if you weren't already. Good to see that you're "on it"!

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

#96

Post by Cyph0n »

ci5er wrote: post #95
Cyph0n wrote: post #94

Earlier quoted context omitted.

I read through Tygar and Yee's paper on secure boot during my research. Their work was very good to be frank. They foresaw most of the recent developments in TPM design, which I thought was quite impressive.

Oh - cool. It wasn't clear to me from your top-level comment how far back you'd gone. Even though it's old, I still think it's pretty good, and thought you should be made aware if you weren't already. Good to see that you're "on it"!

Thanks for mentioning it regardless! I guess you are bound to miss something when sifting through past work on a topic.

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

#97

Post by SEJeff »

So FWIW, I asked about how Redhat signs their packages some time ago (about 6-7 years ago!) and was introduced to Fedora's "Signing Server" service, which is entirely open source. The email in full is:

    Hi Jeff, good to hear from you.
    
    There's really two parts to our signing server; the first is the
    separation of signing to a separate machine with the associated
    client/server and ACL controls, and the second is the interface to the
    nCipher HSM. The first part we've not made open because it's quite
    specific to Red Hat internal build systems and our kerberos setup.
    
    The second part is mostly straightforward use of nCipher utilities but
    includes a patch to GNUpg which I was originally going to make public
    but came into difficulty because it requires headers from the nCipher
    developer kit, and linking to it, and it's under a very non-compatible
    license. Given the cost of nCipher HSM units we didn't think other
    projects would want that solution either.

    So I'd actually prefer to point you to the work that has been done on
    a signing server for Fedora, which is open. See
    http://fedoraproject.org/wiki/ReleaseEngineering/Projects/SigningServer
    The Fedora folks looked into various hardware solutions too which were
    cheaper and didn't have the proprietary API issues, I can't find a
    link to that at the moment but Jesse Keating 
    should be able to give you more info.

    Hope that's a good starting point...
If anyone is interested, the project is actually named Sigul and is located at:

https://fedorahosted.org/sigul/

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

#98

Post by lisper »

saganus wrote: post #91
lisper wrote: 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?

TOTP is tricky because that requires a real time clock, which the SC4-HSM does not have. That would require adding a battery and associated power management circuitry, which would considerably increase the cost. However, you could run a driver on the host machine that provided the time to the HSM, which would still securely store your secret key. But then you could only use it on a machine that had this driver installed. So yes, it's possible, but it's not straightforward.

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

#99

Post by hlandau »

pzb wrote: post #35
danpalmer wrote: post #31

I'd like to address the difference between a SmartCard and an HSM as I feel like the author doesn't acknowledge some of the practical differences. While at the core they are both "hardware security", i.e. a physical chip that implements security, an "HSM" as I have commonly seen the term used is a completely different thing in most other ways. An HSM is typically a 1-2U server, that is designed to provide high throug…

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.

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

#100

Post by [deleted] »

EvilTerran wrote: post #81
pmarreck wrote: post #74

Earlier quoted context omitted.

Is there any way to do what a HSM does, in software? (Maybe with OS support)

Not really, no. AIUI, the whole point of having a hardware security module is that it only leaves a very narrow attack surface (ie, the protocol for communicating with the device) for malicious software to try to exfiltrate the sensitive data through, with no way to get around it - so if that interface is sufficiently hardened, you should be secure regardless of any weaknesses elsewhere in the system. In contrast, wh…

[deleted]
Post reply on HN