CWE-1297 Detail

CWE-1297

Unprotected Confidential Information on Device is Accessible by OSAT Vendors
Incomplete
2020-08-20
00h00 +00:00
2023-06-29
00h00 +00:00
Notifications for a CWE
Stay informed of any changes for a specific CWE.
Notifications manage

Name: Unprotected Confidential Information on Device is Accessible by OSAT Vendors

The product does not adequately protect confidential information on the device from being accessed by Outsourced Semiconductor Assembly and Test (OSAT) vendors.

CWE Description

In contrast to complete vertical integration of architecting, designing, manufacturing, assembling, and testing chips all within a single organization, an organization can choose to simply architect and design a chip before outsourcing the rest of the process to OSAT entities (e.g., external foundries and test houses). In the latter example, the device enters an OSAT facility in a much more vulnerable pre-production stage where many debug and test modes are accessible. Therefore, the chipmaker must place a certain level of trust with the OSAT. To counter this, the chipmaker often requires the OSAT partner to enter into restrictive non-disclosure agreements (NDAs). Nonetheless, OSAT vendors likely have many customers, which increases the risk of accidental sharing of information. There may also be a security vulnerability in the information technology (IT) system of the OSAT facility. Alternatively, a malicious insider at the OSAT facility may carry out an insider attack. Considering these factors, it behooves the chipmaker to minimize any confidential information in the device that may be accessible to the OSAT vendor.

Logic errors during design or synthesis could misconfigure the interconnection of the debug components, which could provide improper authorization to sensitive information.

General Informations

Modes Of Introduction

Implementation

Applicable Platforms

Language

Name: Verilog (Undetermined)
Name: VHDL (Undetermined)
Class: Not Language-Specific (Undetermined)

Operating Systems

Class: Not OS-Specific (Undetermined)

Architectures

Class: Not Architecture-Specific (Undetermined)

Technologies

Name: Processor Hardware (Undetermined)
Class: Not Technology-Specific (Undetermined)

Common Consequences

Scope Impact Likelihood
Confidentiality
Integrity
Access Control
Authentication
Authorization
Availability
Accountability
Non-Repudiation
Gain Privileges or Assume Identity, Bypass Protection Mechanism, Execute Unauthorized Code or Commands, Modify Memory, Modify Files or Directories

Note: The impact depends on the confidential information itself and who is inadvertently granted access. For example, if the confidential information is a key that can unlock all the parts of a generation, the impact could be severe.
Medium

Potential Mitigations

Phases : Architecture and Design
  • Ensure that when an OSAT vendor is allowed to access test interfaces necessary for preproduction and returned parts, the vendor only pulls the minimal information necessary. Also, architect the product in such a way that, when an "unlock device" request comes, it only unlocks that specific part and not all the parts for that product line.
  • Ensure that the product's non-volatile memory (NVM) is scrubbed of all confidential information and secrets before handing it over to an OSAT.
  • Arrange to secure all communication between an OSAT facility and the chipmaker.

Detection Methods

Architecture or Design Review

Appropriate Post-Si tests should be carried out to ensure that residual confidential information is not left on parts leaving one facility for another facility.
Effectiveness : High

Dynamic Analysis with Manual Results Interpretation

Appropriate Post-Si tests should be carried out to ensure that residual confidential information is not left on parts leaving one facility for another facility.
Effectiveness : Moderate

Vulnerability Mapping Notes

Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comment : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Related Attack Patterns

CAPEC-ID Attack Pattern Name
CAPEC-1 Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-180 Exploiting Incorrectly Configured Access Control Security Levels
An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack.

NotesNotes

This entry might be subject to CWE Scope Exclusion SCOPE.SITUATIONS (Focus on situations in which weaknesses may appear); SCOPE.HUMANPROC (Human/organizational process; and/or SCOPE.CUSTREL (Not customer-relevant).
This entry is still under development and will continue to see updates and content improvements.

References

REF-1113

Provably-Secure Logic Locking: From Theory To Practice
Muhammad Yasin, Abhrajit Sengupta, Mohammed Thari Nabeel, Mohammed Ashraf, Jeyavijayan (JV) Rajendran, Ozgur Sinanoglu.
https://dl.acm.org/doi/10.1145/3133956.3133985

REF-1114

Trustworthy Hardware Design: Combinational Logic Locking Techniques
Muhammad Yasin, Jeyavijayan (JV) Rajendran, Ozgur Sinanoglu.
https://link.springer.com/book/10.1007/978-3-030-15334-2

Submission

Name Organization Date Date release Version
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna Intel Corporation 2020-05-29 +00:00 2020-08-20 +00:00 4.2

Modifications

Name Organization Date Comment
CWE Content Team MITRE 2021-07-20 +00:00 updated Related_Attack_Patterns
CWE Content Team MITRE 2022-04-28 +00:00 updated Applicable_Platforms
CWE Content Team MITRE 2022-06-28 +00:00 updated Applicable_Platforms
CWE Content Team MITRE 2023-01-31 +00:00 updated Maintenance_Notes
CWE Content Team MITRE 2023-04-27 +00:00 updated References, Relationships
CWE Content Team MITRE 2023-06-29 +00:00 updated Mapping_Notes