The security of a chip and the product it goes into, from start to finish: security objectives and assets, threat modelling and attack surface analysis, security requirements and compliance targets, a security architecture with roots of trust, secure boot, key management, secure debug, isolation and countermeasures, secure design and security verification, attack testing on silicon, supply chain integrity and secure provisioning, certification and assurance, release, vulnerability response, security updates and the end of security support.
Chip and product security lifecycle: 13 stages, 15 gates of its own and 4 hand-offs to the Product lifecycle, from Security Objectives & Asset Identification to End of Security Support.
13 stages, 15 gates of its own and 4 hand-offs to the Product lifecycle. Each stop opens its stage; each sign opens its gate. Point at a stop or tab to it to read what the stage is for. What the codes mean
In collaboration with The Digital Electronics Blog (opens in a new tab)
An outlined sign with an arrow is a hand-off: the gate is owned by the Product lifecycle, where this lifecycle hands its work on.
In collaboration with The Digital Electronics Blog (opens in a new tab)
Deciding what the product must protect, for whom and to what level: naming the security owner, adopting a secure development lifecycle, listing the assets (keys, firmware, user data, design secrets, device identity, configuration), setting the security objectives and the assurance level the markets expect, and writing the security plan.
Security concept approval gate, owned by the Product lifecycle (Concept approval)Security objectives agreed gate
Describing the attackers in scope and their access (remote, local, physical and invasive), mapping every interface and state through which an asset could be reached, analysing the attack paths for each asset and rating the risk, then deciding for each risk whether to mitigate, accept, transfer or avoid it.
Turning the threat model into verifiable security requirements, each traced to the threat it answers, and setting the compliance targets: the certification schemes and assurance levels to aim for, the regulatory security requirements of each market, export classification of the cryptography, and the security protocols the product must interoperate with.
Security requirements baselined gateAssurance and compliance plan agreed gate
Designing how the chip meets its security requirements: the hardware root of trust, the secure boot chain, key storage, key management and provisioning, secure debug and device lifecycle states, isolation between trusted and untrusted software, cryptographic accelerators and their interfaces, random number generation, and the countermeasures against side-channel and fault injection attacks.
Building the security blocks and the code around them: the root of trust, fuse and key storage controllers, cryptographic accelerators with their countermeasures, access control and isolation logic, debug authentication, and the boot ROM and security firmware, following secure coding and design rules and reviewed by people outside the design team.
Showing before tape-out that the design meets its security requirements and resists the attacks in the threat model: formal proofs of security properties such as access control and information flow, directed and random negative testing, fault injection simulation, pre-silicon leakage assessment of the cryptographic blocks, firmware security testing and a review of the traceability from threats to tests.
Attacking the real silicon: penetration testing of interfaces, debug and boot, side-channel evaluation of the cryptographic implementations, fault attack testing with voltage, clock, electromagnetic and optical methods, interoperability testing of the security protocols, and recording any weakness found as security errata with a fix or a mitigation.
Protecting the product between design and the customer: control of design data and masks, provenance of IP and components, key generation and injection during test, device identity and certificates, locking of test and debug modes before shipment, secure handling at foundry, assembly and test sites, and the controls that prevent counterfeit, overproduced or recycled parts reaching customers.
Obtaining independent evidence of the product's security where the market asks for it: preparing the security target and the evidence package, supporting an accredited laboratory through its evaluation under public schemes such as Common Criteria, FIPS 140-3, PSA Certified or SESIP, and assessments under ISO/SAE 21434 or IEC 62443, then keeping the certificates valid as the product changes.
Evaluation evidence submitted gateCertification achieved gate
Approving the product for shipment from a security point of view: every security requirement verified or its risk accepted, certificates and declarations in place, production keys and provisioning running, the software bill of materials published, the secure integration guide issued to customers and the incident response process ready before the first part ships.
Handling security issues after release through a product security incident response team: a public way to report vulnerabilities, triage and severity rating, reproduction on silicon, root cause, fix or mitigation, coordinated disclosure with the reporter and affected customers, a CVE identifier where it applies, and a published security advisory.
Keeping shipped products secure: building, signing and releasing security updates for firmware and software, revoking compromised keys or images and preventing rollback to vulnerable versions, notifying customers, keeping certificates and regulatory reports current, and reviewing the security support plan as the product ages.
Security update released gateSecurity support review gate, owned by the Product lifecycle (Lifecycle review)
Ending security support in an orderly way: announcing the end of security support with enough notice, issuing the final security update and advisory, guiding customers to supported products, retiring production keys and certificates safely and archiving the security records for as long as they must be kept.
End of security support notice gate, owned by the Product lifecycle (End of support)End of security support gate, owned by the Product lifecycle (End of support)
An outlined sign with an arrow is a hand-off: the gate is owned by the Product lifecycle, where this lifecycle hands its work on.
The full lifecycle detail, with its charts, flows, tables and every section, is for registered members. Registration is free and takes a minute. You come back to this page afterwards.