Skip to main content
Version: v1.1

Security Model

Introduction​

This section documents the security architecture of AosCore — the mechanisms that establish trust, protect communication channels, manage cryptographic identity, and control access to system resources. Understanding the security model is essential for OEMs deploying AosEdge Units, as it governs how Nodes authenticate, how services obtain credentials, and how the system maintains integrity from initial provisioning through ongoing operation.

AosCore's security model is built on a certificate-based identity system managed by the Identity and Access Manager (IAM). Every component in the system — CM, SM, IAM, and MP — authenticates using X.509 certificates issued through a controlled provisioning workflow. All inter-component communication is protected by mutual TLS (mTLS), and private keys can be stored in hardware security modules via the PKCS#11 standard.

Security Architecture Overview​

The security architecture rests on four pillars:

PillarDescription
Certificate-based identityEvery Node and component has a unique cryptographic identity established through X.509 certificates. Certificates are organized by type (e.g., client auth, server auth) and managed through configurable certificate modules.
Mutual TLS (mTLS)All gRPC communication between components uses mutual TLS — both client and server present certificates and verify each other's identity. This prevents unauthorized components from joining the system.
Hardware security (PKCS#11)Private keys and certificates can be stored in hardware security modules (HSMs) or trusted execution environments (TEEs) through the PKCS#11 interface, protecting cryptographic material from software-level extraction.
Controlled provisioningA Node must complete a provisioning workflow before it can participate in the system. Provisioning establishes the Node's cryptographic identity by generating keys, creating certificate signing requests (CSRs), and applying signed certificates.

Trust Model​

AosCore implements a hierarchical trust model:

Cloud CA (root of trust)
└── Unit certificates
    ├── CM certificates (cloud communication, SM controller)
    ├── SM certificates (CM client connection)
    ├── IAM certificates (public server, protected server)
    └── MP certificates (inter-node transport)

Trust anchors:

  • The cloud Certificate Authority (CA) is the root of trust for the entire system
  • Each Node's IAM instance acts as the local trust anchor — it holds the CA certificates and issues/manages component credentials
  • On multi-Node Units, the Main Node's IAM is the central authority that can forward provisioning operations to Secondary Nodes

Trust boundaries:

BoundaryProtection
Cloud ↔ UnitTLS with server certificate verification; CM authenticates to cloud using its certificate
Component ↔ Component (same Node)Mutual TLS over gRPC — both sides present IAM-issued certificates
Node ↔ Node (inter-node)TLS-encrypted transport channels (vchan or socket) authenticated with IAM-issued certificates
Service ↔ Functional ServerSecret-based access tokens — services receive a unique secret at registration that grants access to specific functional server permissions

Certificate Lifecycle​

Certificates in AosCore follow a managed lifecycle:

  1. Key generation — IAM generates a key pair (RSA 2048-bit or ECDSA P-384) through the PKCS#11 module
  2. CSR creation — IAM creates a Certificate Signing Request with the appropriate subject and extended key usage (client auth, server auth, or both)
  3. Certificate signing — the CSR is submitted to the CA (via the cloud during provisioning) and a signed certificate is returned
  4. Certificate application — IAM stores the signed certificate chain in the PKCS#11 module and makes it available to the requesting component
  5. Certificate renewal — before expiration, IAM can generate a new key pair and CSR to obtain a renewed certificate
  6. Certificate validation — IAM periodically validates stored certificates, identifying and cleaning up invalid certificates and orphaned keys

Each certificate type is managed by a dedicated certificate module configured in the IAM configuration file. A module defines the PKCS#11 library, token slot, key algorithm, maximum certificate count, and extended key usage requirements.

Access Control​

AosCore implements a service-level access control mechanism through the Permission Handler:

  • When a service instance is deployed, SM registers it with IAM along with its declared permissions
  • IAM generates a unique secret token for the instance and stores the permission mapping in memory
  • The service uses this secret to authenticate with functional servers
  • Functional servers validate the secret against IAM to determine what operations the service is allowed to perform

This model ensures that services can only access the functional server capabilities explicitly granted to them during deployment.

PKCS#11 Integration​

All cryptographic key storage in AosCore is abstracted through the PKCS#11 interface. This provides:

  • Hardware security — keys can be stored in dedicated HSM hardware, TPM chips, or TEE secure enclaves
  • Software fallback — software-based PKCS#11 implementations (e.g., SoftHSM) can be used for development or platforms without hardware security
  • Token management — IAM manages PKCS#11 tokens including initialization, ownership, and PIN-based access
  • TEE support — the implementation supports Trusted Execution Environment login types (public, user, group) for platforms with ARM TrustZone or similar TEE capabilities

The PKCS#11 module configuration specifies the library path, slot selection (by ID, index, or token label), user PIN path, and file ownership (UID/GID) for secure access control at the OS level.

Provisioning​

Before a Node can participate in the AosEdge system, it must be provisioned. Provisioning is a one-time setup process that:

  1. Takes ownership of the PKCS#11 token (sets the owner password)
  2. Generates key pairs for each configured certificate type
  3. Creates CSRs and submits them for signing
  4. Applies the signed certificates to establish the Node's identity
  5. Transitions the Node from "unprovisioned" to "provisioned" state

Provisioning is initiated through IAM's protected API and requires a password for authorization. On multi-Node Units, the Main Node's IAM can forward provisioning operations to Secondary Nodes through the Node controller's bidirectional streaming connection.

A Node can also be deprovisioned — this clears all certificates and keys, returning the Node to an unprovisioned state.

Section Contents​

This section covers the security model in detail across the following pages:

  • Certificate Architecture — the complete certificate hierarchy, trust chains, certificate types, and module configuration
  • Provisioning Workflow — step-by-step provisioning sequence including cloud interaction and multi-Node provisioning
  • Access Control — the permission model, secret-based authentication, and functional server access