You are here

“What” is Edge-to-Cloud Security? | 赛普拉斯半导体

“What” is Edge-to-Cloud Security?

By Michael Schy, Solutions Architect for the Specialist IoT team at Amazon Web Services and Erik Wood, Director of the Secure MCU Product Line at Cypress, an Infineon Technologies Company.

This blog is part of a series on IoT security. The previous blog, Why IoT Security Matters, and Who Can Help?, discussed how newer “smart” IoT devices without embedded security are putting users’ data and safety at risk. California now requires all manufacturers to include built-in security for connected IoT devices sold in the state, with at least nine other states and the EU about to follow suit. Today, IoT manufacturers are facing the challenge of designing high-standard security measures into resource-constrained products.

Today’s IoT edge devices need to adhere to several requirements of power, price, and processing. If that isn’t enough, these connected products should also have the same airtight, A-Class processor grade security that is employed by PCs, smartphones, and cars.

So how do you achieve internet-grade security in a cloud-connected IoT edge device and remain price competitive? The answer lies in secure microcontrollers.

Today’s secure MCUs help IoT manufacturers design products that comply with the latest security legislations and requirements. These devices come preconfigured to support hardware root-of-trust that are ready for field-provisioning and internal processing resource isolation which ensures that if one area is compromised, the entire device is not.

Secure MCUs also implement hardware accelerated cryptography that offers features like True Random-Number Generator (TRNG) and can generate random cryptographic keys from within the device. Essential for necessary security operations like secure boot and authentication, both features also meet the Federal Information Processing Standard (FIPS) 140-2, Level 1.

Hardware Root-of-Trust:

Just as humans use ID cards, unique biometric features, and passwords to protect their transactions, all devices that are trusted to connect to the cloud need a unique hardware-based root-of-trust to prove who they are. The root-of-trust is the device’s identity and it is bound to the owner of the device. Some techniques recommended by Arm’s Platform Security Architecture include eFUSES and the use of Physically Unclonable Function (PUF) “digital fingerprint” technology.

A hardware root-of-trust is the foundation on which all secure operations of a computing system depend. It contains the keys used for cryptographic functions and enables a secure boot process. It is inherently trusted, and therefore must be secure by design. Multiple hardware roots-of-trust may be used for different applications and they can be bound to different application owners. Some examples where these roots-of-trust are used include booting into a secure and trusted state (Secure Boot), secure firmware updates, attestation, and hardware-based transport layer security (TLS).

Hardware roots-of-trust often come in the form of cryptographic keys which must be logically and securely stored for use and used in a secure processing environment.

Secure Boot

Secure Boot means that the MCU boots into an expected and trusted known good state. Booting to a known good state requires that when a system powers on, every step of boot code validates the next before launching it. A root-of-trust validates the first boot step and every follow-on step validates the next layer of firmware until the entire application is running.

Firmware Updates

Conducting a secure firmware update is very important to fix bugs and discovered security vulnerabilities. It is also important for the protection of the application’s IP.

Hardware-Based TLS

Hardware-based TLS is far more secure than software-only, which leaves cryptographic keys exposed. TLS is the common protocol to encrypt data that travels over networks, especially Wi-Fi. It is vital that the keys used for this type of encryption are securely stored on the chip and the encryption processing is done in a secure processing environment.

Attestation

Remote attestation is a method by which an edge device (client) authenticates its hardware and software configuration to a remote host cloud platform (server) or vice versa. The goal of remote attestation is to enable the challenger to determine the level of trust in the integrity of the attestator.

Secure Key Storage

The logically secure storage of keys in the MCU is vital. It’s not only important to isolate keys from access by the non-secure processing environment where the communication stack lives but also important to isolate different sets of keys from various trusted applications within the Secure Processing Environment. Trusted Firmware-M (TF-M) offers a secure partition manager (the secure operating system that manages the secure processing environment) to enable this.

Field Provisioning

Most secure semiconductors, such as those used for payment cards or SIM cards, undergo bulk provisioning at the factory. Because of this, orders made by customers are non-cancellable and often require minimum order quantities. However, this paradigm is shifting to the point where small- to- medium-volume IoT device makers are now able to take advantage of field provisioning without being burdened by strict supply-chain requirements.

Secure and Non-Secure Processing Isolation

Isolating key storage and cryptographic operations, as well as other secure applications, from the communication stack is critical on an MCU. To do this, a secure MCU must offer both a Secure Processing Environment and a Non-Secure Processing Environment. This isolation can be achieved by either virtualizing a single core or by utilizing two distinct, physically separated cores that use Inter-Processor Communication (IPC) to communicate between them.

PSoC 64® Standard Secure AWS Solution

Fortunately, the Arm® Cortex®-M-based MCU industry has created several open-source communities to create the firmware required to support these key capabilities for secure devices. TF-M.org and Linaro are examples of these communities. Infineon has been a leader in these open-source communities supporting the launch of the PSoC 64 product line. One key family member of the PSoC 64 product line is the PSoC 64 Standard Secure AWS solution which implements open-source security software stitched together with Amazon® FreeRTOS, optimized to work right out the box.

This solution comes backed by a rigorous Amazon qualification process; libraries with inputs from Infineon, Arm, and Amazon; the Free RTOS kernel from FreeRTOS.org; access to the Amazon IoT Device Defender service; and a convenient certificate management system. The benefits of this pre-integrated solution include risk mitigation, cost savings, and fast time-to-market.

Conclusion

When it comes to connected devices, security threats are a very real possibility. Both governments and industry have responded with legislation and standards to mitigate risk. Internet-grade security in a low-cost and resource constrained device is hard but achievable. Secure MCU manufacturers, open-source firmware and cloud powerhouses know how to solve the problem. Infineon and AWS have collaborated to make developers’ lives simple by providing products, both on the device and cloud end of the ecosystem, that do all the secure connectivity work for IoT devices intended for connecting to AWS services.

To learn more about the PSoC 64 product line, please email erik.wood@infineon.com. To order the PSoC 64 Standard Secure AWS development kit, click here. To download our latest white paper, please click here.

And be sure to read our next blog, which will dive deeper into the topic of how to securely connect an IoT device to the AWS Cloud.


About the Authors:

Erik Wood is the Director of the Secure MCU Product Line at Cypress, an Infineon Technologies Company.

Erik spent the first 14-years of his career at various wireless sensor network startups. In 2010, he joined a small group of cryptographic security experts led by the world-renowned cryptographic leader, Dr. Whitfield Diffie, to build a startup that designed lightweight cryptography for resource constrained IoT devices. Realizing the challenges in getting customers to pay for non-NIST certified cryptography, Erik transformed the startup into a Security Software Services business, providing power and processing optimized versions of cyphers supported by NIST Suite B. Following which, Erik joined Cypress through the acquisition of Ramtron. At Cypress, Erik started out by working on F-RAM technology for passive RFID and secure memories and was then pulled in to run the product line for secure microcontrollers and differentiated security software.

Erik has more than a decade of experience in global wireless security standards, including serving as the Chair of the US delegation to ISO for Security in RFID, as well as the Chair of the NFC Forum Security Committee. Erik holds a bachelor’s degree in Electrical Engineering from UCLA and a corporate MBA from Santa Clara University.

Michael Schy is a Solutions Architect for the Specialist IoT team at Amazon Web Services and is responsible for IoT architecture programs, partner enablement, design and integration support, and workshops within his team. He has over 30 years of leading-edge technology experience with over 20 years focused on wireless and embedded technologies. Michael has a BSEE from The Ohio State University and an MBA from Northwestern’s Kellogg School of Management. Michael has done a prodigious amount of system, hardware, and software design and implementation work in the cellular, automotive, and IoT industries.

本网站上的所有内容和材料均“按原样”提供。赛普拉斯半导体公司及其各个供应商对这些材料用于任何用途的适用性不作陈述,并且对关于这些材料的所有担保和条件概不负责,包括但不限于有关适销性、针对特定用途之适用性、权利和不侵犯任何第三方知识产权的所有暗示担保和条件。赛普拉斯半导体公司不授予任何明示或暗示的许可(无论是以默许方式或是任何其他方式)。使用本网站上的信息可能需要第三方的许可,或赛普拉斯半导体公司的许可。

本网站上的内容可能包含或必须遵守关于使用的特定准则或限制。所有帖子和使用本网站上的内容都必须遵守本网站的条款与条件;使用这些内容的第三方必须同意遵守任何限制或准则,并遵守本网站的条款与条件。赛普拉斯半导体公司及其供应商保留随时对内容和材料、产品、计划和服务进行纠正、删除、修改、增强、改进或其他变更,或者移动或终止任何内容、产品、计划或服务的权利,恕不另行通知。