Trust and Internet Identity Meeting Europe
2013 - 2020: Workshops and Unconference

Cryptech Update

(Leif Johansson)

Cryptech in particular deals with high value federations and important metadata with need of private keys. Also time variation of crypto implementations are one very common way of leaking information.

This update is presented to inform the community in relation to the stage the project is and the fact that there will be a commercial product coming out of the project in the next 1-2 years.

Leif: We started this a few years ago. Some people who were servers quickly realised that the interesting attacks on math. You look at the algorithms, they are pretty good but the can sometimes be implemented. So you could break popular VPNs. Implementation is everything. If you can’t trust your implementations you can’t trust anything. If you try to address specific issues, high key value management situations. Anything where you would do asymmetric crypto you need to keep the key private. You want to have some sort of a thing. It’s tempting to just grab a computer and put a lock on it, computers are bad with protecting a side channel. They are mostly side channel devices. Really good at making sure that you don’t need radio waves. To stick a probe into key master memory and also they try to do constant time information. Time variations for crypto information. We started out doing the crypto project with having trusted implementations of a full crypto stack with as much hardware as we can manage. We spent a lot of time doing theoretical and empirical research. Really easy to build, doesn’t require any special components, can build the design over anything you can find in the shop. During testing, we found bugs in the code that can validate the commercial RNDs in the military applications. Apart from the RND we have an FDPA(?) cost and time is really important because it limits the information. We have a small microcontroller that can control everything and a third small CPU that only monitors 10% and controls most of the key memory. The idea is that you would hook up your sensor package. You should be able to shoot a bullet through the HSM and the master key memory would need to burn faster than the bullet. You need to react faster than that. We have a simple fast small piece of microcontroller that is running 5 or 50 lines of code.

That pre-kills flash memory?

L: Yes, you must use the SD wrapper. You can have flash for stuff that is encrypted. There is an architecture you can go on a supply and have this developer board but it isn’t really a product. The project or some of the principles have a stock up company to make a product out of this. That company has a seat in the stock produce that looks like first gen products. Hopefully in a year or two you will be able to buy something that looks like this.

David A: What is the approx. price?

L: 1200$ for an alpha board, most of the cost is a huge FDPA, you can write your own software for it so if you have stuff that you want to run in the trust balcony (?) this is the big challenge involved in doing stuff like this. VHDL are not self-hosted languages so it’s quite difficult plus the final phase for producing firmware…

Are you aware of the authorities to reverse engineer?

L: We are talking to some of those devs. We are talking to german devs that are trying to build an opensource version for bitstream.

What type of devices will be available? USB keys or?

L: These are going to be slightly bigger. USB keys would be really hard to fit the design parameters. The problem is that they would buy a smart guard or usb key and I usually tell them you are sort wasting your money you are sticking your think with most known types of protection next to wifi guard, its not inconceivable that the attacker could whistle away RF leakage on your usb key. It would be pointless for us to build an opensource and rely on their SSS. Its on the webpage.

Some codings are working at one of the larger bitstream..

L: I would be surprised because I know that we are talking to German speaking developers.