32-Bit MCUs
-
32-Bit MCUs
- SAM 32-bit MCUs
- PIC 32-bit MCUs
- CEC 32-bit MCUs
- Legacy Products
- Development Boards
- Software Tools for PIC, SAM and AVR MCUs
-
Applications, Reference Designs and Solutions
- Audio Player/Recorder
- Bluetooth® Low Energy-Based Weather Station
- Die Cutting Machine
- Fitness Tracker/Wearable Solution
- Graphical User Interface
- Human Machine Interface (HMI) for Diagnostic Tool
- Location-Tagged SOS, Asset Tracking or Vehicle Tracking
- Motor Control
- Robotic Vacuum
- SD Card Audio Player
- Smart Home Lock
- TCP/IP Networking
- USB Device/Host Applications with 32-bit Microcontrollers
- USB Mass Storage Device with Multiple Drives
- Wi-Fi® Remote Control for Lighting or Appliances
- 32-bit Embedded Security
- 32-bit Functional Safety
- 32-bit Motor Control
- 32-bit Low Power
- Graphics
- Softpacks
- Other Tools and Resources
- Third Party Partners
- PIC18F to PIC24F to SAMD2x Migration and Performance Enhancement Guide
Secure Your World with Security-Focused MCUs
With the rapid expansion of 5G cellular networks and growing cloud computing infrastructure, developers of networking and data center equipment are seeking new ways to ensure that operating systems remain secure and uncompromised. Security threats are increasing exponentially in terms of frequency, targeted devices, malignancy and costs of attacks. In today’s vast interconnected world, the need to provide greater security within a product or system is becoming a standard requirement. You need to design robust, connected and secure systems to stay one step ahead of the criminal element and prevent theft of software, hardware, intellectual property and data, or communications services.
The CEC1302, CEC1702 and CEC1712 are full-featured 32-bit Arm® Cortex®-M4-based microcontrollers (MCUs) that enable secure boot of system firmware, providing an immutable identity and a root of trust to ensure that the firmware is untouched and hasn’t been corrupted. These devices can be used as stand-alone MCUs, while also providing easy-to-use firmware authentication, public key and customer-specific pre-provisioning flexibility to minimize your risk.
Soteria Custom Firmware
- Designed to be used in conjunction with the CEC1702 and CEC1712
- Speeds adoption and implementation of a secure pre-boot platform
- Simplifies code development and reduces risk
CEC1712

- Ensures in-field security and firmware updates with key revocation and code rollback protection
- Complies with NIST 800-193 guidelines; protects, detects and recovers from corruption for total system platform firmware resiliency
CEC1302

CEC1702

- Reduces compute time with the hardware cryptographic cipher suite
- Protects secrets with encryption
- Validates firmware has been digitally signed and untouched using public key cryptography
What Is Soteria Custom Firmware?
According to leaders in the industry, the pre-boot environment has come under attack via rootkits and bootkits. These types of attacks are insidious and not detectable by high-level operating systems or anti-virus software. Secure boot is a security standard to prevent against attacks to the pre-boot firmware environment.
Soteria is highly configurable custom firmware that runs on CEC17x2 devices to provide a complete platform to establish a chain of trust for platform firmware resiliency. Soteria-G1 runs on the CEC1702Q-S1 and Soteria-G2 runs on the CEC1712Q-S2. The Soteria solution is designed to work with virtually any application processor that meets two criteria:
- The application processor can be held in reset, and
- The application processor loads its first code from SPI-Flash
The Soteria secure boot firmware provides a platform firmware resiliency solution that meets the NIST SP 800-193 guidelines. It uses the immutable secure bootloader implemented in CEC1702/CEC1712 ROM as the system Root of Trust (RoT). The secure bootloader loads, decrypts and authenticates the firmware from the external SPI Flash. The validated CEC1702/CEC1712 code is designed to authenticate the application processor firmware in the same SPI Flash. Up to three additional SPI Flash components can be supported.
Soteria prevents the system from booting unless the application host’s firmware that is stored in the external SPI Flash is authentic code signed by the OEM. It offers security features to authenticate and optionally decrypt the SPI Flash image in the external SPI Flash device.
The application processor can utilize the crypto resources in the CEC1702/CEC1712 to authenticate other code in the system, thereby extending the chain of trust to ensure that all code running in the system is authorized. Soteria uses the same mechanisms to ensure that platforms only perform secure firmware updates.
By design, the Soteria can be a simple black-box secure boot solution or customizable firmware that provides secure boot, extended security features and runtime secure commands via a host interface.
Soteria is available under a Signed License Agreement (SLA). Contact a Microchip sales representative or authorized worldwide distributor to execute the SLA.
Security Capabilities
The CEC1x02 device family provides a variety of robust hardware based crypto algorithms to meet your protection needs.What is Secure Boot?
Everybody today is worried about security. We see the market moving to authenticated boot as a way to protect your overall system. One of the worries is that when you try to boot your system, it won’t work because someone has compromised it.
One solution being adopted is secure boot which ensures the integrity of the software running on a platform. We provide secure boot capabilities to ensure the authentication of the embedded firmware prior to boot of the system. Secure boot relies on public/private keys to verify the digital signature of the code before execution. This confirms that only the code which you intend to be loaded is loaded and used, protecting your system from malicious code. Every time you boot the machine, you have the exact same expectation of the performance of your machine.
What Is Key Revocation?
Key revocation allows public/private key pairs used for authentication to be permanently retired. This feature may be used as a preemptive solution for aging keys or as a defense mechanism if a private key becomes compromised, allowing the code image to be altered or hacked by an unauthorized entity. Key revocation is a simple method for preventing code signed by a specific key from being used in the system. The system must implement multiple keys to use the key revocation feature.
What Is Code Roll-back Protection?
Code roll-back is used when you need to prevent an old image from running. This should be performed using a secure update process.
Which Crypto Curves Are Supported?
The types of crypto curves that are supported are AES256, SHA-512, RSA-4096, ECDSA, Curve25519, Ed25519, True Random Number Generator and Public Key Engine (PKE).
Crypto Parametrics | CEC1302 | CEC1702 | CEC1712 |
---|---|---|---|
Symmetric Encryption | AES128, AES192 and AES256 Modes: ECB, CBC, OFB, CFB, CTR | ||
Hashing | SHA-1, SHA-256 | SHA-1, SHA-256, SHA-384, SHA-512 | |
Public Key Engine (PKE) RSA | RSA-512 to RSA-2048 | RSA-1024 to RSA-4096 | |
ECC | Keys from 160 to 256 bits in GF(p) | 192 to 521 bits in GF(p) 160 to 571 bits in GF(2m) Curve25519 | |
DSA | No | ECDSA, EC-KCDSA, Ed25519 | |
Other | No | Miller-Rabin Primality Testing | |
Modular Arithmetic Primitives | |||
Random Number Generator | True RNG | ||
1K FIFO for pre-calculation | |||
Monotonic Counter | No | Yes | |
User Programmable OTP | 500 bits | 2.5 Kbits | 4 Kbits |
Field Programmable | No | Yes | |
Memory Protection Unit | No | Yes | Yes |
Secure Boot | |||
Integrity | SHA256 | SHA256 | SHA-384 |
Authentication | No | ECDSA-P256 | ECDSA-P384 |
Encryption (optional) | No | ECDH-P256/AES-256 | ECDH-P384/AES-256 |
Attestation | |||
DICE | No | 1st Mutable Code | In ROM |
UDI | No | Factory Provisioned (optional) |