Hacker News Reader

Comment by Cyph0n | Hacker News Reader

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?

View on HN

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 how touchy these babies were when they first came out:

  - http://www-03.ibm.com/security/cryptocards/pciecc2/overview.shtml

EDIT: What the hell. Here's Bennet Yee's PhD thesis. So you don't have to convert it from PostScript. (That said - this is a nasty image scan - you might want to do that anyway!)

  - http://www.dtic.mil/dtic/tr/fulltext/u2/a281255.pdf

I don't think I'm going to be able dig around for the extant Usenix papers from that era on the topic right now.

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.

> Do you guys think something like this could be patented > and/or commercialized?

I would definitely be interested if it's general purpose and open/verifiable.

I think it would make sense if you teamed up with an insurance company. That way, you could prove your technology once, to the insurance company, and sell devices with insurance against compromise. So all your potential customers wouldn't have to audit your technology, since this has been taken care of by the insurance company.

Yes, that is the key issue: companies won't use such a module unless it is verifiable and does what it claims to do. I guess the first step would be to propose an open standard and a sample implementation of such a module. I don't think we're there yet though.

I'm hoping to focus my PhD on trying to come up with a solution to address the issue above. In other words, how can you design chips that can be verified (at all levels) without exposing your IP to a third-party? Furthermore, can this be done at runtime; e.g., could there be a syscall that queries the state of the hardware your software is running on? Cisco is one company that is particularly interested in solutions to both of these problems and is funding multiple research groups to explore these issues.

The issue of trust is solved if you can find a trustworthy intermediary, like an insurance company, to financially guarantee your products against compromise. Insurance is the tried and true method for transferring risk from one party to another. I'm certain there are plenty of customers who would find an insurance by eg. AIG sufficient to do business, without needing to know the internals of the hardware you produce. I know I would.

Edit: I now see that you are referring to someone attacking the module, rather than the module having a backdoor. I agree that insurance is a good way to avoid financial loss, but it doesn't at all address the backdoor issue.

> The issue of trust is solved if you can find a trustworthy intermediary

No it isn't solved at all, because that assumption breaks down very easily, especially now that we know for a fact how invasive surveillance and backdoors have become.

For example, a Chinese company who would like to use such a product would reject a certification by a US or European insurance company, and rightly so. The same applies to a US company with Chinese insurance. The requirements for trust become exceedingly more difficult to meet once you start dealing with military contractors, law enforcement, etc. So where do you propose insuring the hardware module? The US? What if China proves to be a larger market? How about if you want to sell the tech in the EU? It's a rabbit hole of "trust" imo.

This is why an objective verification function would make things much more straightforward for chip designers and fabless semiconductor IP companies. And if you can objectively verify the hardware at runtime, you get even more useful guarantees.

I completely understand that the use of a trustworthy third-party is sometimes necessary, such as in X.509, but when it comes to circuit design, I think we need to and can do better than that.

Since you're doing research in this area, have you taken a look at something like https://www.dyadicsec.com/ at all? I looked at the whitepaper a while ago, and it seemed to make sense, though I was way out of my depth.

No, I have not actually. I will definitely check the whitepaper out. Thanks!

> patented

I hope not.

> commercialized

I hope so.

I think Intel has done something similar to what you are looking for: http://www.intel.com/content/www/us/en/architecture-and-tech...

No, that's different. The crypto is done in hardware, yes, but keys and plaintext are still seen in software, and software is inherently untrusted. Our aim is to support use cases where you do not want software to handle anything.

I think Intel's SGX is a better solution for hardware-supported software isolation, but it still isn't widespread and has a number of weaknesses.

> I think Intel's SGX is a better solution for hardware-supported software isolation, but it still isn't widespread and has a number of weaknesses.

It's not really usable at all right now, but I'm cautiously optimistic that a version of Linux coming soon will support it on a CPU coming eventually.

(The relevant CPU feature is IA32_SGXLEPUBKEYHASH. Until that feature is available, SGX is every bit as worthlessly locked down as the worst GlobalPlatform gadgets IMO.)

Kaby Lake does not appear to have this feature.

Reply on news.ycombinator.com