path: root/transcripts/silicon-salon/crossbar.mdwn

# Crossbar at Silicon Salon #1

video: <https://www.youtube.com/watch?v=F6rjYPNE1-4>

I won't give my whole background but I'm very much a semiconductor person rather than from the blockchain community. I wanted to open with an observation that has struck me for a while. There are really quite different cultures here. In chips, it's super expensive to develop a chip. Rather than thinking in terms of cost to acquire a customer, we think of the tooling cost and our key metric is gross margin. You have to design a chip for multiple purposes. To do one chip is a huge deal, so we don't kickoff chips with the same fluidity that you guys kickoff a new github repository. It's a different way of thinking.

The main point here is to say that you can't be too insular in the thinking. Crypto wallets is using semiconductors that are largely designed not for you but designed for other purposes. Look at a typical MCU in a wallet, you probably have a hundred such MCUs in your house. They were designed for those purposes, not for cryptocurrency. So you have to be aware of the larger world and why those semiconductors came into being, and I think to harmonize requirements that's how good semiconductor support comes into being.

Crossbar is foundationally a memory-technology company. I think it's relevant here in talking about crypto-wallets. To give some background, any kind of non-volatile memory that you're used to dealing with like SDcard, USB thumb drive, these are based on floating gate where a bunch of electrons are trapped in an oxide between insulators. This works down to, you can integrate with this logic, it works down to about 40 nm. Below that, the volume, you need a certain volume of electrons for the memory to be readable and the volume is just too small below 40 nm. So this has led to a field called emerging memories: what are we going to do for advanced nodes so that we can embed non-volatile memories? Crossbar is a leader in one type of that memory called resistive memory.

To explain the relevance to hardware wallets, flash trapped charge can be easily it's a charge you cna read it with an electron microscope. And also because it's a bunch of electrons trapped in a small space, they want to get away from each other, and it may leak over time. If you put something in your desk drawer and pick it up a few years later, it may not be working anymore, particularly if you happened to store something magnetic in the same dawer. It's susceptible to electromagnetic fields, radiation, etc. 

Resisitve memory is highly immune to physical attack. We have given our memory to a teardown house and even with de-laminating layer by layer they were unable to extract data from the memory. It also does not have this repulsive leaking effect. We say it lasts for 150 years and that's based on analysis, obviously we haven't been around for 150 years. It's robust against electromagnetic field and various other forms of aging. Also, it can be integrated with advanced nodes and that logic.

When you think about embedded memory, you think about logic and memory together. This is how we got into security products in general. Looking at hardware wallets, most of them are close to the following architecture: there's a microcontroller borrowed from the consumer market, not shielded, generally 40 nm and above because it needs memory and memory doesn't work below 40 nm, and perhaps a secure element (SE) borrowed from the SIM card market or banking market, which does have shielding. Some SEs are simple state machines, some have a small MCU, a few pins, typically they would support RSA and NIST P-256 so legacy inapplicable cryptography when you're talking about hardware wallets. It's hard to go beyond a black box view, you don't get an open devkit or anything like with a consumer MCU.

A lot of hardware wallets if they have an SE at all, they might pull the secrets into a physically not shielded chip which seems like a problem. Just making important decisions like, am I paying to the right address? That's UI software executing in an unshielded chip driving a display. If you can capture bus traffic and crack it offline with arbitrary compute power, that's different than having to crack it in situ. The speed and size is large, and the memory is readable and perishable. I also hear a lot of complaints about no devkit access or almost black box on SEs, no flexibility.

The coloring in my slide is meant to be physical countermeasure shields. Let me explain what I mean by that. It's not obvious when you read datasheets of these parts, but if you look at teardowns you come to realize that a few small chips for banking and SIM have physical protection. Whereas on the MCU side, any general purpose MCU evne if it says secure that kind of refers to logical security meaning when I write this address I can no longer do x. But that logic is really just transistors performing logic, but if you can disrupt that operation then the logical security malfunctions. Physical security means attempting to prevent that kind of disruption attack. I'm not going to go through this slide. There's 20 or so physical countermeasures techniques. I'll quote one. If you put on the top metal layer a complex mesh that has maybe 64 or 128 lines spaghettied around each other and connected to sensors, if you try to FIB or probe then you will short or break this and this is caused a protective active mesh. This is just one of about 20 techniques. They have to be built into the chip and distributed throughout the layout; in the marketplace, you see this only on the SEs and not on a general purpose microcontroller.

When you talk about FIBing and probing, 28nm is by itself is of course more resistant to attack than 40 nm. The effectiveness of countermeasures is much more effective and more dense when you have it at a more advanced process.

Some of the things that Crossbar is thinking about as architectural improvements, just talking generally here, about how to improve these. These are things that we can discuss today at least. Being a memory technology developer, first let's replace the secret storage or the boot code or backup that you would typically do on an SDcard and replace that with a private and persistent memory that is robust. Also, I think extending physical countermeasures over more function, very important functions typically on this MCU side whether 2 chips, co-package, or monolithic, however you do it, but it seems extending physical umbrella of countermeasures seems to be key. There are critical decisions going on in the MCU side, after all. You could also say crypto is evolving quickly, and hardware implementation will never keep up with the rate of innovation in blockchain. But to the extent to that the MCU is secure, then you can think of it as a secure processor even for cryptographic operations. Moving forward in node size is of course good for size, cost, everything. And making sure it's not just a black box that is hard to use. These are some of the items we think are important for going forward in semiconductors for hardware wallets.

We're going to hold questions until after the presentations.