Definition
Comparing the cryptographic hash or derivative of a pointer's value to an expected value.
How It Works
Pointer Authentication (frequently referred to as PAC, although the technique is properly Pointer Authentication) is a security feature to provide protection against attackers with memory read/write access. A Pointer Authentication Code (PAC) is a cryptographic hash or derivative computed on the value of a pointer and some additional context information which can then provide a cryptographically strong guarantee about the likelihood that a pointer has been tampered with by an attacker.
Although pointers are 64 bits, most systems have a substantially smaller virtual address space, leaving unused bits in pointers that can store the value of the PAC, this can be done to reduce memory space requirements. One implementation is in ARMv8.3-A. A PAC is computed over the 64-bit pointer value and a 64-bit context value. Instructions are introduced to deal with pointers: one category to compute and insert the PAC into a pointer, another category to verify the pointer and invalidate the pointer if the PAC does not check, and a third category to remove the pointer and restore the original value without verifying.
The ARM standard specifies a cryptographic algorithm called QARMA-64 (designed by Qualcomm) to compute the signature, although this algorithm is not required. The architecture provides for five secret 128-bit Pointer Authentication keys: two for instruction pointers, two for data pointers, and a general key for signing larger blocks of data.
Considerations
In the ARM implementation, the mechanisms above for manipulating PACS are provided, but it is up to the code developer to manage the keys for the cryptographic algorithm.
A known potential limitation of PACs concerns signing gadgets. Under certain circumstances PACs can be bypassed by forcing the system to run a signing gadget which will allow the signing of arbitrary pointers to occur.
Implementation perspective
Pointer Authentication should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes the relevant system, activity, and evidence sources.
Use the technique to increase the effort, prerequisites, or constraints an adversary must overcome before exploitation or misuse succeeds.
Questions to ask
- Which component, configuration, credential, interface, or behavior is being hardened?
- What secure baseline or policy defines the intended state?
- How are exceptions approved, time-limited, and reviewed?
- How is the hardened state verified after deployment and significant change?
Evidence and validation
- Approved hardening standards and configuration baselines
- Automated configuration or integrity assessment results
- Exception records with owners, rationale, and expiration dates
- Test results demonstrating that the intended restriction is enforced
Common failure patterns
- A secure setting is documented but not enforced consistently across the environment.
- Hardening breaks required functions and is permanently weakened through undocumented exceptions.
- Teams measure deployment of a product rather than verification of the hardened condition.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- Pointer Authentication on ARMv8.3 ↗Qualcomm Technologies, Inc · Qualcomm Technologies, Inc · SpecificationReference
- Examining Pointer Authentication on the iPhone XS ↗Project Zero, Google, Inc · Brandon Azad · InternetArticleReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.