"Unlocking a device" often means activating certain unadvertised debug and manufacturer-specific capabilities of a device using sensitive credentials. Unlocking a device might be necessary for the purpose of troubleshooting device problems. For example, suppose a device contains the ability to dump the content of the full system memory by disabling the memory-protection mechanisms. Since this is a highly security-sensitive capability, this capability is "locked" in the production part. Unless the device gets unlocked by supplying the proper credentials, the debug capabilities are not available. For cases where the chip designer, chip manufacturer (fabricator), and manufacturing and assembly testers are all employed by the same company, the risk of compromise of the credentials is greatly reduced. However, the risk is greater when the chip designer is employed by one company, the chip manufacturer is employed by another company (a foundry), and the assemblers and testers are employed by yet a third company. Since these different companies will need to perform various tests on the device to verify correct device function, they all need to share the unlock key. Unfortunately, the level of secrecy and policy might be quite different at each company, greatly increasing the risk of sensitive credentials being compromised.
| Impact | Details |
|---|---|
|
Modify Memory; Read Memory; Modify Files or Directories; Read Files or Directories; Modify Application Data; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism |
Scope: Confidentiality, Integrity, Availability, Access Control, Accountability, Authentication, Authorization, Non-Repudiation
Once unlock credentials are compromised, an attacker can use the credentials to unlock the device and gain unauthorized access to the hidden functionalities protected by those credentials.
|
| Phase(s) | Mitigation |
|---|---|
|
Integration |
Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.
|
|
Manufacturing |
Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.
|
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. | 200 | Exposure of Sensitive Information to an Unauthorized Actor |
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | Category Category - a CWE entry that contains a set of other entries that share a common characteristic. | 1195 | Manufacturing and Life Cycle Management Concerns |
| Phase | Note |
|---|---|
| Integration | |
| Manufacturing |
VHDL (Undetermined Prevalence)
Verilog (Undetermined Prevalence)
Class: Compiled (Undetermined Prevalence)
Class: Not OS-Specific (Undetermined Prevalence)
Class: Not Architecture-Specific (Undetermined Prevalence)
Other (Undetermined Prevalence)
Class: Not Technology-Specific (Undetermined Prevalence)
Example 1
This example shows how an attacker can take advantage of compromised credentials.
When the credentials of multiple organizations are stored together, exposure to third parties occurs frequently.
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 1417 | Comprehensive Categorization: Sensitive Information Exposure |
Rationale
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.Comments
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.Maintenance
| CAPEC-ID | Attack Pattern Name |
|---|---|
| CAPEC-560 | Use of Known Domain Credentials |
| Submissions | ||
|---|---|---|
| Submission Date | Submitter | Organization |
|
2020年05月29日
(CWE 4.1, 2020年02月24日) |
Parbati Kumar Manna, Hareesh Khattri, Arun Kanuparthi | Intel Corporation |
| Modifications | ||
| Modification Date | Modifier | Organization |
|
2025年04月03日
(CWE 4.17, 2025年04月03日) |
CWE Content Team | MITRE |
| updated Demonstrative_Examples | ||
| 2023年06月29日 | CWE Content Team | MITRE |
| updated Mapping_Notes | ||
| 2023年04月27日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2022年10月13日 | CWE Content Team | MITRE |
| updated Description | ||
| 2021年10月28日 | CWE Content Team | MITRE |
| updated Demonstrative_Examples, Description | ||
| 2020年08月20日 | CWE Content Team | MITRE |
| updated Demonstrative_Examples, Description, Related_Attack_Patterns | ||
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.