Secure Authentication for Any Core, Any Cloud
During this session, you will learn about the implementation and logistic challenges to add a secure authentication in a system in the first part of the lecture. Then, you will be exposed to Microchip Trust Platform for the CryptoAuthentication and the problems are addressed to make secure authentication more accessible to the fragmented IoT market.
HI Curiousc,
The ATECC608A goal is to protect keys to isolate them from FW, SW, manufacturing operations, etc... the device doesn't solve everything in security. It looks like you are talking about mounting some man-in-the-middle attack on the communication protocol here. The way the ATECC608A would help is again by isolating the keys involved with the communication. If during a communication protocol attack a vulnerability affects the keys, the device would mitigate the consequence. In addition, if keys used in the communication are mixed in the FW, they become under the remote control of the attacker. The ATECC608A create somewhat of an air gap between the application code and the keys that are supposed to stay secret, unaltered, yet trusted. You could also envision many other attacks, but if you agree with the fact that once you obtain a private remotely, you could control an entire fleet, then you can hopefully see the benefit of the device capability to isolate keys.
Thanks you - this helps. I have one follow-up question to make sure I understand properly. Let's say that I don't fully trust the host CPU - the one that is connected to the ATECC608A. How does isolating the keys help me - if at all? I'm far from a crypto expert and so don't fully understand the "mitigation" you talked about. Can you elaborate a bit? Thanks.
You use a key word here "Trust the CPU", the only way to trust the CPU is that if the CPU has integrated secure key storage. A few MCU or MPU will claim have such integrated feature or will have such integrated feature. So let me answer with several analogies. Servers have Intel process that have 4 layers of code access, what they are doing is isolating critical firmware in 4 zones from most critical to least critical (nothing new), you might hear the buzz word of TrustZone, doing what Intel did but among 2 zones. This firmware isolation. A good practice to help you "trust" the critical code running in you systems. Back to the server example, yet servers do you use TPM (trusted platform modules) which are discrete secure key storage. Because the server providers like HP, Dell, AWS, Azure, Google, Facebook, do not trust the keys to be mixed with the CPU. Code has bugs and always will and you don't want those bug to affect you keys. If not, your design could be severely impacted. If your key is altered, you will need to revokate it and update it. But you will update it in a CPU you cannot trust. So the system is stuck. Another example, mobile phones keep the key in the sim card which is physically isolated from the CPU, payment card (smartcard) are secure key storage in a credit card physically isolated from the payment terminal CPU. Isolation the secure key storage is a common practice. In addition to the isolation from FW, it helps with the logistics and cost of logistics. It's easier and cheaper to use a discrete secure key storage than an integrated solution.
Very helpful - thanks
While the ATECC608A is tamper-resistant, why couldn't an attacker simply target the host CPU to compromise the communications with the cloud?