71–80 of 139 posts
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 but we will be shipping again in early January.
What is the problem to take a 10$ stm32f discovery board and use it as TPM. There are different flash protections: 1) you can read/write flash via JTAG 2) you can only write flash, but not read the old one 3) you can't rewrite flash, neigher can you read it. You will still have to implement USB communication, but there is already a lib from STM for it. Some models also have generous flash (in MB ranges). You can use…
I had to look up TPM, I didn't realize there was an open standard for crypto processors. Is it safe to say that most HSMs are TPMs?
TPMs in most cases are based on smart cards but can also be implemented in a TEE (Trusted Execution Environment). Security does not always mandate tamperproof hardware.
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?
> 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 t…
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.
HSMs are shit. In a previous role we used a major vendor's HSM to protect our private keys. VERY expensive kit, more expensive than the load balancers and servers combined. We needed to use Elliptic Curve keys for a particular customer - so it got even more expensive as we had to buy: 1. A license from the LB vendor to use the HSM 2. A licence from the HSM vendor to use EC with the LB. ... even though they trumpeted…
Earlier quoted context omitted.
> 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 t…
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 a…
Earlier quoted context omitted.
This exactly. You use a HSM so it doesn't matter if your server gets popped.
I think one should be really careful making statements like this. In the case where an HSM is used for e.g. database encryption, one absolutely still cares. The attacker can politely ask the HSM to decrypt all the data. On the bright side, you didn't lose the key, and your HSM should at least securely log the fact that all your data just walked out the door. For SSL offload the situation is less dire, but it is total…
HSMs are shit. In a previous role we used a major vendor's HSM to protect our private keys. VERY expensive kit, more expensive than the load balancers and servers combined. We needed to use Elliptic Curve keys for a particular customer - so it got even more expensive as we had to buy: 1. A license from the LB vendor to use the HSM 2. A licence from the HSM vendor to use EC with the LB. ... even though they trumpeted…
Is there any way to do what a HSM does, in software? (Maybe with OS support)
Earlier quoted context omitted.
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 a…
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…
> 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.
HSMs are shit. In a previous role we used a major vendor's HSM to protect our private keys. VERY expensive kit, more expensive than the load balancers and servers combined. We needed to use Elliptic Curve keys for a particular customer - so it got even more expensive as we had to buy: 1. A license from the LB vendor to use the HSM 2. A licence from the HSM vendor to use EC with the LB. ... even though they trumpeted…
Is there any way to do what a HSM does, in software? (Maybe with OS support)
However, you'd still be vulnerable to someone gaining root access on your Vault server. A true HSM uses physically secure memory and a dedicated cryptoprocessor to make it impossible for the secret to ever be leaked, even if the host OS is compromised. This isn't really something that's possible in software alone.
(In fact, the Vault documentation even mentions that you might still want to use a dedicated HSM for security, since they implement a plugable mechanism for secret storage.)
That said... you could use a TPM chip or ARM TrustZone to implement true TPM functionality. It's still a hardware based solution, but it's hardware that's much more affordable and possibly already inside your computer.
What is the problem to take a 10$ stm32f discovery board and use it as TPM. There are different flash protections: 1) you can read/write flash via JTAG 2) you can only write flash, but not read the old one 3) you can't rewrite flash, neigher can you read it. You will still have to implement USB communication, but there is already a lib from STM for it. Some models also have generous flash (in MB ranges). You can use…
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.