ℹ️
Tracked metadata: Sourced from EMVCo's public document index. PCI Watch records each document's details and its extracted text so changes can be tracked over time; the document PDF itself is hosted by EMVCo.
View on EMVCo.com →

SE Bulletin nº 14: System on Chip (SoC) Evaluation Scoping

v1.0 Security Evaluation Process & Bulletins
Chip & Platform
Extracted document text

EMVCo's index flattens the document's layout, so this text is best used for searching and comparing versions rather than reading end-to-end.

EMVCo SEWG Bulletin 14 First Edition – February 2019 System on Chip (SoC) Evaluation Scoping SoC products are widely used in the mobile computing and IoT markets. This bulletin clarifies EMVCo’s policy for scope definition of System on Chip (SoC) evaluations as well as SoC specific security features and/or package that can be included within such evaluations and the rating methodology to be used. It also highlights differences between a smart card IC and a secure subsystem within an SoC. Any questions in relation to this bulletin should be directed to the Security Evaluation Working Group (SEWG) Secretariat at securityevaluation@emvco.com. Applicability This Bulletin applies to: • EMVCo IC Product Providers • EMVCo Recognized Security Evaluation Laboratories Related Documents • EMV Security Guidelines, EMVCo Security Evaluation Process, v5.2, March 2018 • JIL - AAP Amendment for TOE Package Removal, v1.0, To be published Effective Date • 1 February 2019 © 2019 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV<sup>®</sup> is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Page 1 Background A System on Chip (SoC) integrates all the components of a computer or similar electronic system. It may contain digital, analogue, mixed-signal, and often RF functions — all on a single substrate. SoCs are very common in the mobile computing and IoT markets because of their low power consumption and one of their components can be dedicated to providing cryptographic and/or security services with tamper resistance similar to a smart card integrated circuit. The term ‘secure subsystem’ will be used throughout this bulletin to refer to this component. In order to be certifiable by EMVCo, the secure subsystem must be physically isolated from the rest of the SoC, i.e. it must have clear physical boundaries with regard to the rest of the circuitry on the SoC that is considered as untrusted by the secure subsystem. In other words, the secure subsystem cannot be mixed with SoC features, be spread within the SoC or split into multiple parts integrated in various physical locations in the SoC. Within the EMVCo security evaluation programme, SoCs are considered as a particular type of Integrated Circuit (IC). The next sections of this bulletin provide details on the scoping of SoC evaluations due to SoCspecific considerations and differences with classical smart card ICs. In addition to these principles, existing evaluation guidance and security guidelines for Integrated Circuits remain applicable to SoC evaluations. Differences between a smart card IC and a secure subsystem within an SoC This section describes the main differences between a smart card IC and a secure subsystem within an SoC: • There are other components - physically and logically - around the TOE on the same SoC die. Hence potentially no direct physical access to all TOE interfaces is possible for an SoC contrary to a smart card IC where I/O signals to send APDUs, reset signal, test interface / signals and power lines are accessible. • The surrounding system might have the following influence: o Sensitivity of the SoC to environmental conditions and fault injection. o Surrounding noise by inherent signal influence of the host SoC (including code being executed on the host SoC). • An SoC has different functional properties: o A secure subsystem may run at higher frequency (e.g. factor 10x 100Mhz – 1GHz) o Usually a secure subsystem is less constrained in power. o More than one security feature component may run in parallel. • The physical design would differ in terms of: o Additional layers, e.g. redistribution layers added o SoCs may use smaller technology nodes than smart card ICs o Different electrical characteristics, e.g. more capacitance o More I/O signals and interfaces • The life-cycle would potentially differ in development and integration environments for the TOE. The evaluation of a secure subsystem within an SoC deemed for re-integration in any SoC should assure that its security is not based on or influenced by the surrounding SoC. For this reason, the Product Provider shall provide the Laboratory with an appropriate testing environment for the SoC. © 2019 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV<sup>®</sup> is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Page 2 SoC Evaluation Scoping Policy An SoC typically may comprise many, or only a few components such as: • Application Processor • Modem • Embedded memory (RAM, ROM, eNV/Flash memory) and/or interfaces to an external memory • I/O and Interfacing • On-Chip Communication backbone (e.g. on-chip bus or Networks-on-Chip (NoC)) • (Graphics) Processing Unit • Power Management Unit • DSP • Testing / DFT • Isolated secure subsystem • … The Target of Evaluation (TOE) consists of the secure subsystem, its supporting firmware/software, optionally its package and associated security guidance. The final SoC can be provided between deliveryform-extremes, from a bare die to a package which would be unpractical to dismantle without destruction of the SoC. If the SoC relies to some extent on the protection of the package, the laboratory shall analyse the possibilities to remove or circumvent the package protection. This could require deeper analysis of mechanical and/or chemical methods. The secure subsystem provides cryptographic and/or security services, it protects the operation of these services and the corresponding sensitive assets against attacks on the implementation. It is independent from a security point of view, i.e. it holds all relevant security measures and does not rely on protection capabilities from the rest of the circuitry on the SoC. The TOE also includes the supporting firmware/software of the secure subsystem that might be: • Software to start-up, self-test, configure and set the hardware functionality in operation. The firmware is executed immediately after powering the secure subsystem or provides driver functionality. • Internal firmware/software, that comprises all software stored in memories inside of the TOE boundaries, e.g. in ROM or embedded Flash. The secure subsystem provides security mechanisms to protect its software against eavesdropping, modification, rollback, and further attacks. • External firmware/software, that comprises all software stored outside of the physically isolated secure subsystem (e.g. in an external Flash). Since the environment outside the secure subsystem is regarded as untrusted, the TOE needs to enforce particular protection for these data. External firmware/software must be protected against eavesdropping, modification, rollback, and further attacks. Note that software and associated configuration/user data providing higher level functionality might exist and communicate to SoC parts that are external to the TOE via defined interfaces. Operation of such software may rely on the firmware as enabler and driver of the hardware. In other words, this software cannot be executed before it has been securely loaded and enabled by the firmware. It is the Product Provider’s choice to include or not the SoC package and its internal structure in the TOE and to describe/identify this as such in the Product Registration Questionnaire, considering that this would also impact the site audits and product life-cycle. If included as part of the TOE, the package and any information related to the product structure will be mentioned in the ICCN certificate. If the Product Provider does not include the SoC package, then full access to the die – and specifically its secure subsystem – should be possible during the penetration testing phase. In this case, no effort for packaging removal should be included in the attack rating. © 2019 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV<sup>®</sup> is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Page 3 If the Product Provider includes the SoC package and/or the configuration of the SoC surrounding (e.g. wiring, RAM block layout), the evaluation shall cover the removal of the package as part of the attack path. In any case, the Laboratory shall perform relevant penetration tests on samples prepared for the evaluation (as detailed in ‘Delivery of suitable samples for the evaluation’ section below). Attacks will be considered as partial attacks when done on such samples and shall be combined with the rating of the removal or penetration of the package and making the device functional if needed. The following rather provides guidelines than absolute fixed values for the rating of the removal or penetration of the package. When the effort for the removal of the package is considered difficult regarding methods and techniques, the Product Provider has to support the Laboratory with the required information. The guideline for the rating of the SoC package removal considers three levels of effort: Low, Medium and High, as discussed below: • Simple packages, that require low preparation effort using standard chemical etching, mechanical action, re-wiring, or similar for the attack path, are for example: o Conventional smart cards. o Standard plastics like DIP, SOIC, QFP, QFN, ..., BGA (targeting the more accessible side, typically back side for flip chip). • Packages that require medium preparation effort and that have a relatively high risk for fatal damage of the TOE (losing the functionality that is targeted or required for the evaluation) because of special constructions, are for example: o Package-on-Package (POP) with glued interposer board. o Packages with a passive mesh or obstructive wire bonding: this means that the bonding wires are hard to remove/circumvent or hard to re-wire. For example, it requires significant manual reverse-engineering (&gt;1 week) of several hundred pins to be obtained by generating a bonding map. And, effort to translate the bonding map to a bonding machine file format, for the use of an automated bonding machine. Note that if the reverseengineering does not need to be redone in Exploitation phase, consequently, points in Exploitation shall only be given if the remaining attack path still requires specialized equipment or above. o Casting compounds, for example based on synthetic material for example resin, which require material-specific chemistry, as mechanical removal of the package leads to fatal damage of the TOE with high probability. The Laboratory shall provide evidence that using standard chemical methods (for example a wave of hot fuming sulfuric acid, application of fluoric acid or other) lead to fatal damage of the TOE with high probability. • Packages that require high preparation effort, multiple experts and rare bespoke tooling, are for example: o Chip-on-chip with critical functional dependency that require a wing board to be able to work: it is important to consider methods to circumvent dependencies, e.g. run external memory with lower frequency and similar. In this example the TOE is not functional without external memory, or the TOE checks presence of the memory, but the SoC adds no protection means for the TOE. o If there are TOE checks for external components then circumventing these checks matters for the evaluation. o Packages with an active mesh meaning for example that the mesh is connected to the TOE and monitored by the TOE for damages. o Casting compounds, for example on ceramic basis, which cannot be removed without fatal damage of the TOE if using mechanical and also material-specific chemistry. The removal is therefore either not practical to state-of-the-art knowledge, as outlined below, or subject to bespoke methods known to the Product Provider only and shared with the Laboratory in © 2019 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV<sup>®</sup> is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Page 4 the course of the evaluation. This means there should be no publicly known method to remove the package material with low or medium effort or with state-of-the-art chemical methods. The rating for these package removal effort levels is defined as follows: Factors Access to TOE (package removal effort) Low Medium High Identification 0 1 2 Exploitation 0 2 4 Delivery of suitable samples for the evaluation Unlike in the traditional case of a smart card IC, a secure subsystem cannot be provided on its own to the Laboratory and instead, a host SoC will be provided. Therefore, the TOE interface will typically not be directly accessible to the Laboratory in a standalone mode. The Product Provider shall support the Laboratory to access the TOE interfaces, e.g. in cases where the interaction with the TOE will require assistance from other sub-systems in the SoC connected to the TOE. The Product Provider shall provide the Laboratory with: • The TOE in a prepared package (functional bare die or a modified die in a special package to facilitate penetration testing with access to one or both sides of the silicon) that is agreed between the Laboratory and Product Provider considering the available package types and the best case for the attack paths defined. If the prepared package does not allow access to both sides of the silicon, then the Laboratory shall provide a rationale why access to only one side is sufficient. In case the Product Provider provides supporting evidence, the Laboratory shall verify the evidence. • SoC picked from a wafer (bare die). • Functional die as shipped to the customer (may include stacked die such as a DDR chip on top of the SoC). Potentially useful for package analysis if it is part of the TOE. The Product Provider shall support the Laboratory with an evaluation board containing the agreed sample for evaluation and all surrounding components (e.g. PCB, wiring, memories, power management IC) on the board and software configuration in the SoC to operate the TOE. © 2019 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV<sup>®</sup> is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Page 5 Legal Notice This document summarizes EMVCo’s present plans for evaluation services and related policies and is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or non-infringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document. © 2019 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV<sup>®</sup> is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Page 6