Terms and Definitions

CAN Protocols and Higher-Layer Protocols

• CAN. Controller Area Network. A multi-master, message-oriented serial bus standardized in ISO 11898, widely deployed in machinery, industrial automation, and embedded systems. Classical CAN supports 8-byte payloads at up to 1 Mbit/s.
• CAN FD. CAN with Flexible Data-rate. Extension of classical CAN with payloads up to 64 bytes and a higher bit rate during the data phase. Standardized in ISO 11898-1:2015.
• CAN XL. Third-generation CAN, sitting above CAN FD in the CAN family. Payloads up to 2048 bytes and higher data-phase bit rates than CAN FD. Standardized in ISO 11898-1:2024. The cryptographic security extension defined for the CAN XL data-link layer is CANsec.
• CANopen. Higher-layer protocol on top of CAN, maintained by CiA. CANopen CC (for Classical CAN) is specified in CiA 301; CANopen FD (for CAN FD) is specified in CiA 1301. Both define object dictionaries, PDOs, SDOs, and network management primitives.
• CiA (CAN in Automation). International users' and manufacturers' group based in Nuremberg, Germany. Maintains the CANopen specifications (CiA 301 for Classical CAN, CiA 1301 for CAN FD) and the broader CiA document series, including many device and application profiles.
• J1939. SAE higher-layer protocol on CAN used in off-highway, agricultural, construction and some stationary applications. Uses 29-bit identifiers and PGN-based message structure supporting source and destination adressing.
• FireCAN. CAN-based higher-layer protocol used in fire fighting equipment. Original version was "loosely based" on CANopen, now standardization process is underway to harmonize it with CANopen.
  
• CleANopen. CANopen application profile for municipal special-purpose vehicles (refuse collection, street cleaning, winter service). Standardizes the device profiles and process-data exchange between truck body, chassis, and operator console. Specified in CiA 422.

Regulations

• CRA (Cyber Resilience Act). EU Regulation 2024/2847 establishing horizontal cybersecurity requirements for products with digital elements. Annex I lists the essential cybersecurity requirements.
  See Why Now.
• NIS 2 (Network and Information Security Directive). Directive (EU) 2022/2555. Cybersecurity obligations for essential and important entities across critical sectors.
  
  See Why Now.
• Machinery Regulation. Regulation (EU) 2023/1230, applicable from 20 January 2027. Replaces the Machinery Directive and adds explicit cybersecurity-related essential health and safety requirements for machinery, including protection of safety-relevant control signals carried over CAN.
  See Why Now.
• RED (Radio Equipment Directive). Directive 2014/53/EU. Activated for cybersecurity by Commission Delegated Regulation (EU) 2022/30, which adds essential requirements for connected radio equipment. Harmonized standards EN 18031-1/-2/-3:2024 specify the risk-assessment and risk-reduction process.
  
  See Why Now.

Standards and Guidelines

• IEC 62443. Series of international standards for security of industrial automation and control systems. Defines Security Levels SL1–SL4 and detailed system and component requirements. Part 3-2 covers risk assessment, 3-3 system requirements, 4-1 product development lifecycle, 4-2 component requirements.
  See IEC 62443-Style Assessment.
• ISO/IEC 27005. Information security risk management. IT-leaning; oriented to enterprise information assets rather than control-system equipment.
• ISO/IEC 27019. Energy-sector control-systems overlay on ISO/IEC 27002. Used where the deployment is specifically a power-utility installation.
• NIST SP 800-30. NIST Special Publication 800-30. US federal guidance for information-system risk assessments. Documentation-heavy, common in government and government-supplier contexts.
• NIST SP 800-82. NIST Special Publication 800-82, the Guide to Operational Technology Security. The leading US reference for industrial control system cybersecurity, complementary to IEC 62443.
• EN 303 645. ETSI EN 303 645: cybersecurity baseline for consumer Internet of Things devices.
  
• EN 18031. Harmonized standards EN 18031-1/-2/-3:2024 under the Radio Equipment Directive 2014/53/EU as activated by Commission Delegated Regulation (EU) 2022/30. Includes a risk-assessment and risk-reduction process for connected radio equipment.
• BSI TR-02102. BSI Technical Guideline on cryptographic mechanisms: recommended algorithms, key lengths, and operating modes. The reference for "BSI-approved" in this site.
• ISO/IEC 9798. Entity authentication. Multi-part international standard defining mechanisms by which two parties prove their identities to each other. Part 1 covers the general model; Part 2 (ISO/IEC 9798-2) specifies mechanisms using symmetric encipherment algorithms, including the one-pass, two-pass, and three-pass challenge/response constructions.
  
  Used by Secure Object Fieldbus Access.
• NIST SP 800-57. NIST recommendation for key management: the full lifecycle of cryptographic keys, including generation, establishment, storage, rotation, and destruction. The reference for key-management practice cited throughout this site.
• NIST SP 800-108. NIST recommendation for key derivation using pseudorandom functions. Defines the counter-mode, feedback-mode, and double-pipeline constructions that derive many purpose-specific keys from one root key by binding a label and context into each step. The reference for the key-ladder derivation used in symmetric key management.
• NIST SP 800-38F. NIST recommendation for key wrapping: encrypting cryptographic keys under a key-encryption key for protected storage or transport. Specifies the AES key wrap constructions (KW and KWP). The reference for holding root keys outside a hardware module.
• NIST SP 800-90A. NIST recommendation for random number generation using deterministic random bit generators (DRBGs). Specifies the approved DRBG constructions that expand a small seed of entropy into cryptographically strong key material. The reference for how a device turns raw entropy into keys.
• NIST SP 800-90B. NIST recommendation for the entropy sources that seed a DRBG: how to design a noise source, estimate its entropy, and run the health tests that confirm it keeps producing unpredictable output. The reference for validating the hardware random number generator behind key generation.
• ISO/IEC 27001. International standard specifying the requirements for an information-security management system (ISMS): the organizational processes for managing security risk, distinct from the product and component controls of IEC 62443.
• FIPS 140-2. US federal standard of security requirements for cryptographic modules, covering key storage and protection. Superseded by FIPS 140-3 in 2026, though 140-2 validations remain widely referenced. Commonly cited alongside its international counterpart ISO/IEC 19790.
• ISO/IEC 19790. International standard of security requirements for cryptographic modules, the counterpart to FIPS 140-2. The reference for hardware-backed key storage above Security Level 2.
• IEEE 802.1AR. Secure Device Identifier (DevID) standard: a per-device identity credential and certificate provisioned at manufacture. One well-known form of asymmetric device identity.
• SUIT (Software Updates for Internet of Things). IETF firmware-update architecture and manifest information model (RFC 9019 and RFC 9124), often paired with signed firmware updates on constrained devices.
• ANSI X9.24-3. Financial-industry standard for symmetric key management, the home of DUKPT (Derived Unique Key Per Transaction): deriving a unique key per device from a shared root key. Prior art for the derive-from-root approach used on fieldbuses.

Risk-Assessment Vocabulary

• Risk Assessment. Structured process covering identification of assets, threats, attack paths, risk derivation, and treatment selection, as required by CRA Article 13. The CRA does not prescribe a specific methodology.
  See Risk Assessment.
• Vulnerability Scoring. A per-finding severity metric for a specific weakness, distinct from risk assessment.
  See CVSS for CAN.
• CVSS (Common Vulnerability Scoring System). Industry-standard scoring scheme for the severity of software vulnerabilities. CVSS v4.0 is the version expected for CRA vulnerability reporting to ENISA.
  See CVSS for CAN.
• SL (Security Level). IEC 62443 categorization of attacker capability. SL1 is incidental misuse; SL2 is intentional, low resources; SL3 is intentional, moderate resources with technology-specific skills; SL4 is intentional, extended resources with technology-specific skills.
  See IEC 62443 SL2 Requirements.
• SBOM (Software Bill of Materials). Machine-readable list of all software components in a product, in formats such as SPDX or CycloneDX. Required by the CRA.
• Defense in Depth. Security architecture principle of combining multiple, overlapping defensive measures so that the failure of any single measure does not expose the asset. Endorsed by IEC 62443 (zone-and-conduit + SR layering) and NIST SP 800-82.
  See Defense in Depth.
• Zone and Conduit. IEC 62443-3-2 partitioning model. A zone groups components that share security requirements and exposure; a conduit is a communication path that crosses a zone boundary.
  See Zoning and Segmentation.
• EmSA-WP-103. EmSA white paper that establishes a default CVSS v4.0 baseline for an unprotected CAN node, used as the scoring reference throughout this site.
  See the EmSA security white papers.

Threats and Attacks

• Frame Injection. Transmitting CAN frames with arbitrary CAN IDs from a node not authorized to use those IDs, exploiting the absence of source authentication on classical CAN.
  See Protocol Weaknesses.
• Spoofing / Masquerading. Transmitting CAN frames under another node's CAN ID to impersonate a legitimate sender. Closely related to frame injection: injection is the act of transmitting unauthorized frames, spoofing or masquerading is doing so under a borrowed identity.
  
  See Protocol Weaknesses.
• Replay Attack. Re-sending previously captured legitimate frames to cause unintended state changes. Classical CAN has no native replay protection.
  See Protocol Weaknesses.
• Sniffing. Passive observation of bus traffic by a node with physical or logical access to the medium. CAN is a broadcast bus, so every node on a segment sees every frame by design; sniffing requires no privilege escalation, only access. T
  See Protocol Weaknesses.
• Bus Flooding. Transmitting frames at higher priority than legitimate traffic, or forcing error frames, to deny legitimate communication on the bus. On CAN the dynamic is inverted relative to internet DoS: a single malicious node can overload an entire network because every node sees every frame.
  See Bus Load Monitoring.

Cryptographic Primitives and Keys

• AES-128-GCM. Advanced Encryption Standard with 128-bit key in Galois/Counter Mode. Authenticated encryption (AEAD) algorithm, recommended by BSI TR-02102 and the AEAD primitive used by SPsec on CAN FD, Secure Object Fieldbus Access (SOFA) at the application layer, and the CANopen secure bootloader.
• AEAD (Authenticated Encryption with Associated Data). A cryptographic mode that provides confidentiality, integrity, and authenticity in a single operation. Supports multiple algorithms including AES-128-GCM , Ascon and ChaCha20-Poly1305.
• SHA-256. Secure Hash Algorithm producing a 256-bit (32-byte) digest, specified in FIPS 180-4. A one-way fingerprint of data with no key involved: the same input always yields the same digest, and any change to the input changes it unpredictably. On CAN security it underpins firmware image digests, secure-boot measurements, HKDF derivation, and Ed25519 signatures.
• HKDF-SHA-256 (HMAC-based Key Derivation Function). Key-derivation function built on HMAC-SHA-256, specified in RFC 5869. Expands one root secret into several purpose-specific keys by binding a salt and a context label into each derivation, so a device can hold a single root and derive per-device, per-purpose, or per-session keys on demand.
  See Symmetric Key Management.
• Ed25519. Edwards-curve Digital Signature Algorithm over Curve25519, specified in RFC 8032. A compact, fast public-key signature scheme: one party signs with a private key and any holder of the 32-byte public key can verify, with no shared secret to distribute. Suited to firmware signing and device identity, where open verification or non-repudiation is needed.
• X25519. Elliptic-curve Diffie-Hellman key agreement over Curve25519, specified in RFC 7748. Lets two parties derive a shared secret over an untrusted channel without a pre-shared key, giving forward secrecy when ephemeral keys are used. The shared secret is passed through a key-derivation function such as HKDF rather than used directly.
• Ascon. NIST-standardized lightweight cryptography family (selected 2023, published as the NIST Lightweight Cryptography standard). Includes Ascon-AEAD and Ascon-Hash variants. Designed for resource-constrained devices.
  
• ChaCha20-Poly1305. AEAD construction combining the ChaCha20 stream cipher with the Poly1305 message-authentication code. Specified in RFC 8439. Often faster than AES-GCM in software when AES hardware acceleration is unavailable; widely used in TLS 1.3 and SSH.
  
• HMAC (Hash-based Message Authentication Code). RFC 2104. Used for short message authentication tags when full AEAD encryption is not feasible.
• MAC (Message Authentication Code). Cryptographic tag attached to a message to authenticate its origin and integrity. Distinct from "MAC address" (Media Access Control address).
• KDF (Key Derivation Function). Cryptographic function that derives one or more working keys from a root secret, typically combining the secret with a salt and context information. Common KDFs include HKDF (RFC 5869). Used in CAN security to derive per-session, per-channel, or per-purpose keys from a long-term pre-shared key without weakening or exposing the long-term key.
• Nonce. Number used once. Value (random or counter-based) that must not be reused with the same key in AEAD constructions. Reuse breaks the cryptographic guarantees of the construction. Nonce management is the trickiest correctness concern in AEAD-based CAN protocols.
• Salt. Value combined with the input to a key derivation function so the same secret produces a different derived key in different contexts. Does not need to be confidential, only unpredictable in the relevant scope. Prevents derived-key collisions across products, deployments, or protocol versions. This is the generic sense; specific salts in this reference name their scope, so see Session Salt and Key-Specific Pre-Shared Salt.
• Session Salt. A non-secret salt written once per power cycle into a write-once-after-reset slot on the server, then combined with a base key to derive the session key. Its security rests on being written once and refreshed each power cycle rather than on secrecy, and the slot may be read back for diagnostics. The session mechanism that uses it is defined by SOFA in EmSA-WP-105; the base-key model beneath it is EmSA-WP-104.
• Key-Specific Pre-Shared Salt. A pre-shared, write-only salt bound one-to-one to a particular key and assigned together with it, used where a cryptographic function needs a salt or nonce longer than the available counters or timestamps can supply. Defined per key in SPsec.
• PSK (Pre-Shared Key). Symmetric key established out-of-band between communicating parties. This reference names each PSK by its function rather than by an internal alias: the Update Key for software-update and configuration-update operations; the Provisioning Key loaded at manufacturing; the Integrator Key for system-level access.
• Update Key. Pre-shared key used to protect software updates and, depending on the system, also configuration updates where a whole configuration table is loaded at once. On CANopen, the Update Key authenticates and (where configured) encrypts the firmware image with AES-128-GCM, and gates entry into the bootloader's update mode via challenge/response.
  
  See Secure Bootloader.
• Provisioning Key. Pre-shared key loaded at manufacturing or initial provisioning, used to bootstrap further keys in the field. Distinct from operational keys; typically used to establish trust before the device enters service so that runtime keys can be loaded or derived securely.
  
• Integrator Key. Pre-shared key established by the system integrator, distinct from the manufacturer's Provisioning Key. Lets the integrator gate runtime access at the system level without exposing the manufacturer's keys. Aligns with the IEC 62443-3-2 split of responsibilities between manufacturer and integrator.
• TLS-PSK. TLS (Transport Layer Security) profile authenticated by pre-shared keys (RFC 4279). Suitable for constrained CAN gateways' external interfaces where certificate handling is impractical.
• cTLS. Compact TLS: IETF draft profile of TLS 1.3 designed for resource-constrained environments and small frames.
• RFC 5869. Specification of HKDF, the HMAC-based key-derivation function used to derive per-purpose keys from a shared secret. The common choice for the key-derivation function referenced under Symmetric Key Management.
• Hardware Security Module (HSM). A small hardware module that stores cryptographic keys and performs operations with them inside a protected boundary, so the keys never appear in ordinary memory. On a fieldbus it typically holds one root from which per-device and firmware keys are derived on demand, keeping secure storage bounded. A secure element is the same idea in a single chip. FIPS 140-2 and ISO/IEC 19790 certify these modules.
  See Secure CAN MCUs.
• Root Key. The single top-level secret of a symmetric key hierarchy, held in a hardware security module and never exported. Every other key is derived from it on demand, so protecting the root protects the whole program. There is exactly one root per scheme; its asymmetric counterpart is the offline signing key whose public half is distributed as a trust anchor.
• Base Key. A generic term for a key that other keys are derived from, rather than one used directly to protect traffic. The exact meaning depends on the scheme, so the term is qualified where it is used. In a manufacturer-side derivation hierarchy a base key sits beneath the root, one per product line or purpose (for example a Production Base Key), and working keys derive from it. In a device-side pre-shared hierarchy (SPsec, EmSA-WP-104) the base keys are the persistent keys a device holds, such as the Provisioning and Integrator keys, from which per-session keys derive.
• Trust Anchor. The public key a verifier holds in order to check a certificate or signature, as defined in RFC 6024. It is the public half that tools and devices carry; the matching private signing key is kept offline by its owner. Compromise of that signing key forges trust for the whole deployment, so it is guarded most carefully. The trust anchor itself is not secret.
• Session Key. The symmetric key that protects traffic on the wire, derived on both peers from a base key and a session salt rather than transmitted. It is short-lived, typically renewed each power cycle, so compromise of one session does not expose the base key it came from. Used this way in SPsec and EmSA-WP-104.
• Key ID. A readable, non-secret identifier associated one-to-one with an installed key. Because base keys are write-only and cannot be read back, a tool has no way to ask a device which key it currently holds; the Key ID closes that gap. It names the key without revealing anything about the key material. Defined per key in SPsec and EmSA-WP-104.
• Factory Device Identity. A manufacturer-installed asymmetric signature keypair that gives a device a permanent, verifiable identity. The private half never leaves the device and the public half is verified against the manufacturer's trust anchor. It is independent of the operational keys and survives a factory restore, so a device can prove what it is at any point in its life. IEEE 802.1AR calls this credential an IDevID. Introduced for the manufacturer-rooted model in EmSA-WP-104.
• Local Device Identity. An integrator-installed asymmetric signature keypair, layered on top of the factory device identity once an integrator has claimed a device. Unlike the factory identity it is erased by a factory restore, along with the rest of the integrator's credentials. IEEE 802.1AR calls it an LDevID. See EmSA-WP-104.
• IDevID. The IEEE 802.1AR name for a manufacturer-installed initial device identity. On this reference it is the factory device identity.
• LDevID. The IEEE 802.1AR name for a locally significant device identity installed by the owner. On this reference it is the local device identity.
• Ownership Voucher. A short, manufacturer-signed statement that binds one device serial to one integrator public key, so an uncommissioned device accepts its first key install only from the integrator the voucher names. It is not secret; its value is that it cannot be forged, and a device verifies it against the manufacturer trust anchor it already carries. Adapted in EmSA-WP-104 from the voucher of RFC 8995 (BRSKI), reduced to what a device with no network stack and no clock can verify.
• Owner Epoch. A monotonic counter carried in an ownership voucher and stored on the device across a factory restore. A device refuses any voucher at or below the highest epoch it has already accepted, so a previous owner cannot re-claim a resold device with an older voucher. See EmSA-WP-104.

Key Provisioning and Lifecycle

• Uncommissioned State. The state a device ships in and returns to after a factory restore. It holds no operational credentials and refuses every bus command except the one that installs the first Provisioning Key, so the device state, not a secret, controls what it will accept. See EmSA-WP-104.
• Device Claim Token. The non-secret, known value a device recognizes while uncommissioned, used only to accept the first Provisioning Key install. It is not a key, not a password, and not an authentication secret, and it becomes invalid once provisioning completes. Naming it explicitly matters for audit: a device that ships in an uncommissioned state accepting one documented command reads as a state machine rather than a default-password violation. See EmSA-WP-104.
• Commissioning Environment. The controlled setting in which provisioning is performed: an isolated bench, or a new-machine bus with no other node powered. The isolation is what protects the first, unauthenticated key install on a device that has no trust established yet. See EmSA-WP-104.
• Factory Restore. The deliberate, destructive return of a device to its uncommissioned state. It erases the base keys, the local device identity, and all configuration, and leaves operational input and output disabled until a new Provisioning Key is installed. The factory device identity and, where used, the owner epoch counter survive it. The reset is graded, from a routine wipe of operational key material that leaves the device owned, up to a full release that clears ownership so the device is unowned again. See EmSA-WP-104.
• Integrator-Rooted. The anchoring model in which a device is born open: it leaves the factory carrying no credential, the integrator installs every root of trust at first commissioning, and the device locks itself afterward. It needs no asymmetric primitive and suits a single integrator running a closed deployment. Its cost is a window between production and commissioning in which only physical and supply-chain control protect the device. See EmSA-WP-104.
• Manufacturer-Rooted. The anchoring model in which a device is born locked: it leaves production already carrying a factory device identity and the manufacturer's trust anchor, so there is no open, unprovisioned window. The integrator verifies an already-trustworthy device, claims it with an ownership voucher, and layers its own keys on top. It suits broad markets and cases where counterfeit devices are a concern, at the cost of a production-line signature and a trust anchor to maintain. See EmSA-WP-104.
• Printed One-Time Token. A per-device secret value printed on the unit, its label, or its packaging, as a code or a QR code, which an integrator's tool must present to claim the device before it will install operational keys. It is the middle option among the claim-ownership gates: stronger than trust on first use, because an attacker on the bus alone cannot claim the device, and lighter than a manufacturer-signed ownership voucher, because it needs no signing infrastructure. Being a printed shared secret, it can be photographed or leaked, so it is only as good as the control of the printed value. It is distinct from the Provisioning Key, which is the credential its presentation gates the install of.
  See Handover.
• RFC 8995. Bootstrapping Remote Secure Key Infrastructure (BRSKI). IETF standard for automated, secure device onboarding using a manufacturer-signed voucher to establish ownership. EmSA-WP-104 adapts its voucher construct to the ownership voucher, reduced to what a constrained fieldbus device with no network stack and no clock can verify.
• Claim Gate. The method by which an uncommissioned device decides whom to accept its first key install from. The token gate accepts an installer that presents the correct Device Claim Token, whether a well-known default or a printed one-time token; the voucher gate accepts only the integrator named in a manufacturer-signed ownership voucher. See EmSA-WP-104.
• Device Capability Level. The ordered classification of what a device's cryptography can do: symmetric only; able to verify a signature it is given; able to sign with an identity of its own; and able to agree a key. Each level is a superset of the one below, and it bounds which claim gates, protection choices, and security profiles the device can use. The boundary that matters most is between verifying and signing, because it separates authorizing an action from proving the device's own identity. See EmSA-WP-104.
• Security Profile. A named, recommended combination of capability level, claim gate, and protection choices, so a device can declare one value and a tool can decide what to expect without inspecting every capability. The profiles range from a controlled-environment symmetric baseline up to confidential key install with a device identity. See EmSA-WP-104.
• Delegation. An owner-signed grant that gives a maintenance tool a scoped subset of the owner's authority, so the tool can act without holding the ownership credential itself. It is one level deep, bound to specific operations and to a device serial or group, and revoked by advancing the owner epoch rather than by an expiry the clockless device cannot enforce. See EmSA-WP-104.

Security Measures and Mitigations

• Anomaly Detection. Monitoring for deviations from a learned or specified baseline of bus traffic, including timing, frame counts, or content patterns. A measure rather than a specification: applied on top of whichever frame-level controls are in place to surface what slipped through.
  See Anomaly Event Monitoring.
• SPsec (CANcrypt V2.0). Security sublayer specification for classical CAN (with limitations) and CAN FD providing authentication and encryption. Specification documents 101–302 are published on esacademy.com.
  See Frame Security.
• CANcrypt. Authentication and encryption layer for classical CAN and CANopen, with a published book and reference implementation at cancrypt.net.
  See Frame Security.
• SOFA (Secure Object Fieldbus Access). Application-layer cryptographic shell for CAN-based fieldbuses. For CANopen, SOFA provides authenticated read or write access to selected Object Dictionary entries. Operational access is protected by a session key derived from an operational base key and a session salt, not by the Provisioning Key. SOFA offers a session-based protocol aligned with TLS-PSK (RFC 4279) and a per-transfer challenge-response protocol, FBsec, aligned with ISO/IEC 9798-2. Where a device can afford it, an optional Ed25519 identity binds a control-plane access to a specific device rather than to mere key possession.
  
  See Secure Object Fieldbus Access.
• CANsec. Cryptographic security extension defined for the CAN XL and potentially CAN FD data-link layer, adding frame-level authentication and optional confidentiality. Analogous in role to MACsec for Ethernet. AES-GCM based. The specification is currently under definition.
  See Frame Security.
• Secure Boot. Boot process that verifies firmware authenticity and integrity before execution, typically using a manufacturer-controlled signing key.
  
  See Secure Bootloader.

Frequently Asked Questions

How is this glossary scoped?

Industrial CAN and CAN FD security only. Entries cover the protocols (CAN, CAN FD, CAN XL, CANopen, J1939, FireCAN, CleANopen), the regulations that drive security obligations in the EU (CRA, NIS 2, Machinery Regulation), the standards that operationalize those obligations (IEC 62443, NIST SP 800-82, EN 303 645, ISO/IEC 9798), the threats and attacks the controls address (frame injection, spoofing / masquerading, replay, sniffing, bus flooding), and the security measures and mitigations on the CAN side (anomaly detection, SPsec, CANcrypt, SOFA, CANsec, secure boot) along with the cryptographic primitives and keys involved (AES-128-GCM, Update Key, Provisioning Key, Integrator Key, authentication key). Automotive vocabulary is deliberately excluded.

Where do these definitions come from?

Each term cites its source standard or specification where one exists. Where a term has multiple meanings across communities (for example MAC, which can mean Message Authentication Code or Media Access Control), the definition here is the one used by this reference and the disambiguation is called out.