6  Authentication and Access Control

Learning Objectives

After completing this series, you will be able to:

  • Build a complete IoT access control system with token-based authentication and role-based authorization on ESP32
  • Implement account lockout policies and comprehensive audit logging to prevent brute force attacks
  • Apply the AAA framework (Authentication, Authorization, Accounting) to IoT security design
  • Design enterprise-grade security patterns including capability-based access control and session management

6.1 Overview

Authentication and access control are the foundational pillars of IoT security. This comprehensive series of hands-on labs teaches you how to build secure access control systems from basic RFID authentication to enterprise-grade capability-based access management.

Through practical ESP32 implementations, you’ll learn the critical distinction between authentication (verifying identity) and authorization (checking permissions), and understand why both are essential for secure IoT systems.

Lockout policy strength is easy to quantify. For a 6-digit token space, brute-force success probability over one day is approximately:

\[ P_{\text{success}} \approx \frac{A}{10^6} \]

where \(A\) is the number of guesses an attacker can submit in 24 hours.

Worked example: If an attacker can try one guess every 2 seconds with no lockout, then \(A = 86{,}400/2 = 43{,}200\) and \(P_{\text{success}} \approx 4.32\%\) per day. With a policy of 5 failed attempts followed by a 10-minute lockout, one attack cycle takes \(5 \times 2 + 600 = 610\) seconds, so \(A \approx (86{,}400/610)\times 5 \approx 708\) guesses/day and \(P_{\text{success}} \approx 0.0708\%\). That is about a 61x reduction in daily brute-force risk from one policy change.

6.2 Learning Path

This content is organized into four progressive chapters, taking you from fundamentals to advanced enterprise patterns:

6.2.1 1. Fundamentals Lab

Difficulty: Intermediate | Time: 2-3 hours

Build a complete IoT access control system with: - Token-based authentication using simulated RFID cards - Multi-level role-based access control (GUEST, USER, ADMIN) - Account lockout policies to prevent brute force attacks - Comprehensive audit logging - Visual and audio feedback systems

What you’ll build: A working ESP32 access control system with 4 LEDs, buzzer, and 2 buttons that demonstrates the authentication to authorization flow.

Start the Fundamentals Lab

6.2.2 2. Security Concepts and Challenges

Difficulty: Intermediate | Time: 1-2 hours

Extend your understanding with: - Security concepts demonstrated in the lab - Real-world application mapping - 5 challenge exercises to enhance the system: - Time-based access control - Two-person rule implementation - Temporary access passes - Anti-passback protection - Emergency override mode

Prerequisites: Complete the Fundamentals Lab first.

Explore Challenges

6.2.3 3. Authentication Concepts

Difficulty: Intermediate | Time: 1 hour

Master the theoretical foundations: - The AAA Framework (Authentication, Authorization, Accounting) - Common security mistakes and how to avoid them - Transitioning from lab implementations to production systems - Real-world examples: AWS IAM, Kubernetes RBAC, OAuth 2.0

Key Learning: Understand how lab concepts map to enterprise security systems.

Learn Core Concepts

6.2.4 4. Advanced Access Control Lab

Difficulty: Advanced | Time: 3-4 hours

Implement enterprise-grade security patterns: - Capability-based access control with fine-grained permissions - Session management with time-limited tokens - Privilege escalation prevention - Token lifecycle management (creation, validation, renewal, revocation) - Attribute-based access control (ABAC) - Separation of duties

What you’ll build: A sophisticated access control system with session tokens, capability management, and context-aware access decisions.

Start Advanced Lab

6.3 Key Concepts Covered

Concept Fundamentals Challenges Concepts Advanced
Authentication vs Authorization ✓ ✓ ✓ ✓
Role-Based Access Control ✓ ✓
Capability-Based Access Control ✓
Account Lockout ✓ ✓
Audit Logging ✓ ✓ ✓ ✓
Session Management ✓
Token Lifecycle ✓
Privilege Escalation Prevention ✓
Attribute-Based Access Control ✓
AAA Framework ✓
Production Patterns ✓

6.4 Suggested Learning Sequence

For Beginners (6-7 hours total):

  1. Fundamentals Lab - Build the basic system
  2. Security Concepts - Understand what you built
  3. Core Concepts - Learn the AAA framework
  4. Pick 2-3 challenge exercises to practice

For Intermediate Learners (8-10 hours total):

  1. Fundamentals Lab - Quick refresher
  2. Complete all 5 Challenge Exercises
  3. Core Concepts - Connect to real-world systems
  4. Advanced Lab - Enterprise patterns

For Advanced Developers (4-5 hours total):

  1. Skim Fundamentals Lab
  2. Jump to Advanced Lab
  3. Review Core Concepts for production insights
  4. Implement custom challenge exercises

6.5 What You’ll Build

6.5.1 Fundamentals Lab Hardware Setup

  • ESP32 DevKit V1
  • 4 LEDs (Green=Access Granted, Red=Denied, Yellow=Status, Blue=Admin)
  • 4x 220 ohm resistors
  • 1 Piezo buzzer
  • 2 Push buttons

6.5.2 Code Skills Developed

  • C++ for embedded systems
  • Security-focused programming patterns
  • State machine design
  • Event-driven architecture
  • Cryptographic primitives
  • Token management

6.6 Real-World Applications

The concepts in these labs directly apply to:

Physical Security:

  • Corporate badge access systems
  • Smart locks and door controllers
  • Data center entry systems
  • Hotel keycard systems

Digital Security:

  • AWS IAM policies
  • Kubernetes RBAC
  • OAuth 2.0 / OpenID Connect
  • API key management
  • JWT token validation

IoT Systems:

  • Fleet authentication
  • Device provisioning
  • Certificate-based device identity
  • Secure firmware updates
  • Remote device management

6.7 Interactive Knowledge Checks

Throughout these labs, you’ll encounter 17 interactive knowledge check questions covering: - Authentication vs authorization distinctions - OAuth 2.0 token lifecycle and device flows - Multi-factor authentication (MFA) in IoT - Certificate-based device authentication - Challenge-response protocols - Biometric authentication at scale - Privilege escalation detection - And more…

Each question provides detailed feedback to reinforce learning.

A smart city lighting system with 5,000 streetlights initially used a shared API key for all devices. After a security audit flagged this as a critical vulnerability, they migrated to per-device X.509 certificates.

Phase 1: Current State (Shared Key)

  • All 5,000 lights use API key: sk_prod_7j2k9m... in firmware
  • Security issue: Extracting firmware from ONE light compromises ALL lights
  • Cannot revoke access to individual lights without fleet-wide firmware update

Phase 2: Certificate Provisioning

  1. Factory stage: During manufacturing, each light receives unique certificate + private key in secure element (ATECC608A)

  2. Certificate structure:

    Subject: CN=LIGHT_001234, O=SmartCity, C=US
Serial: 0x1A2B3C4D
Public Key: ECDSA P-256
Validity: 2024-01-01 to 2034-01-01 (10 years)

  3. Private key storage: Stored in ATECC608A hardware crypto chip, never readable by firmware

Phase 3: Server-Side Changes

  • Mutual TLS on MQTT broker (port 8883)
  • Each light authenticates with its certificate during TLS handshake
  • Server verifies certificate chain against root CA
  • Certificate Revocation List (CRL) checked every connection

Phase 4: Incident Response Improvement

  • Before: Firmware extracted from stolen light allows attacker to impersonate all 5,000 lights
  • After: Stolen light certificate revoked via CRL, only that ONE light loses access
  • Metrics: Compromise impact reduced from 5,000 devices to 1 device

Cost-Benefit:

  • Certificate provisioning: $0.50/device (ATECC608A + factory time) = $2,500 total
  • Avoided breach cost (based on similar incident): $180,000 (forensics + replacement)
  • ROI: (180,000 - 2,500) / 2,500 = 7,100%
Fleet Size Security Need Recommended Method Secondary Option
1-100 devices Low (private network, non-critical) Pre-shared keys (PSK) Username/password over TLS
100-1,000 devices Medium (some exposure, monitoring data) X.509 certificates OAuth 2.0 with device flow
1,000-100K devices Medium-High (actuators, fleet mgmt) X.509 certs + hardware secure element TPM-based attestation
100K+ devices High (critical infrastructure) X.509 + device provisioning service + HSM Mutual TLS + zero-touch onboarding

Decision Criteria:

  1. Can device perform asymmetric crypto? (ECC/RSA)
    • Yes: X.509 certificates
    • No: PSK or symmetric-only methods
  2. How critical is per-device revocation?
    • Critical: Certificates (CRL/OCSP)
    • Not critical: Shared secrets acceptable
  3. Regulatory requirements? (HIPAA, PCI DSS, NERC CIP)
    • Regulated: Certificates mandatory
    • Not regulated: Risk-based decision
  4. Existing PKI infrastructure?
    • Yes: Leverage it (mTLS)
    • No: Consider cloud device provisioning (AWS IoT, Azure DPS)

Cost Analysis (per 10,000 devices): - Shared API keys: $0 initial + $200K breach recovery = $200K risk - X.509 certificates: $5K (provisioning) + $10K/yr (PKI ops) = $55K over 5 years

Common Mistake: Conflating Authentication with Encryption

What practitioners do wrong: They implement TLS encryption for device-to-server communication and assume this also handles authentication.

Why it fails: Standard TLS (without client certificates) provides: - Encryption (confidentiality) - Server authentication (device verifies it’s talking to the real server) - But NOT client authentication (server does NOT verify device identity)

Concrete example:

# ESP32 connects to MQTT broker with TLS (server auth only)
import ssl, socket
context = ssl.create_default_context()
sock = socket.create_connection((broker, 8883))
tls_sock = context.wrap_socket(sock, server_hostname=broker)

This code: - Encrypts data (attacker cannot read messages) - Verifies server certificate (prevents man-in-the-middle) - Does NOT authenticate the device (any device can connect and publish)

Correct approach (add mutual TLS with client certificate):

import ssl, socket
context = ssl.create_default_context()
context.load_cert_chain('device_cert.pem', 'device_key.pem')  # Client auth
context.load_verify_locations('ca_cert.pem')  # Server verification
tls_sock = context.wrap_socket(
    socket.create_connection((broker, 8883)),
    server_hostname=broker
)

Now: - Encryption (confidentiality) - Server authentication (device verifies server) - Client authentication (server verifies device identity via mutual TLS)

Real-world consequence: In 2020, an industrial IoT deployment encrypted all traffic with TLS but had no client authentication. An attacker registered a rogue device on the MQTT broker (which accepted any encrypted connection) and injected false sensor data, causing $340K in manufacturing waste. The broker logs showed “encrypted connection from 192.168.1.x” but could not identify which device. Fix: mutual TLS with per-device certificates + IP allowlisting.

6.8 Prerequisites

Required Knowledge:

  • Basic Arduino/C++ programming
  • Understanding of GPIO operations
  • Basic security concepts

Recommended Background:

Hardware:

  • Access to Wokwi simulator (browser-based, no physical hardware needed)
  • Or physical ESP32 with components for hands-on implementation

6.9 Concept Relationships

How This Module’s Chapters Connect
Chapter Foundation Required What It Teaches Leads To
Fundamentals Lab Basic programming, GPIO Token authentication, RBAC, lockout policies Challenge exercises, concepts
Challenge Exercises Fundamentals lab completion Time-based access, two-person rules, anti-passback Advanced patterns
Core Concepts Understanding of auth vs authz AAA framework, production patterns, security anti-patterns All advanced topics
Advanced Lab Fundamentals + concepts Capability flags, sessions, token lifecycle, escalation prevention Enterprise implementations

Learning Path: Start with Fundamentals Lab (hands-on) then Core Concepts (theory) then Challenges (practice) then Advanced Lab (enterprise patterns)

Key Insight: This module progresses from basic role-based access control (GUEST/USER/ADMIN) to enterprise-grade capability-based systems with fine-grained permissions, demonstrating how production security systems evolve beyond simple role hierarchies.

6.10 Knowledge Check

6.11 See Also

Related Security Modules:

Production Examples:

  • OAuth 2.0 / OpenID Connect - Web and mobile authentication standards
  • AWS IAM - Cloud resource access policies and roles
  • Kubernetes RBAC - Container orchestration access control
  • Active Directory - Enterprise identity and access management

Common Pitfalls

Authentication systems require ongoing maintenance: rotating secrets, renewing certificates, updating password policies, patching libraries, and reviewing access logs. Plan for security operations from day one, not as an afterthought after the system is deployed.

Systems that mix authentication (“is this device valid?”) with authorization (“can this device perform this action?”) become difficult to evolve. Design them as separate, independently scalable components from the start.

Development environments often have weaker security (insecure JWT secrets, debug credentials, no rate limiting) that passes all tests but would fail in production. Run security tests against a production-equivalent staging environment before any release.

Discovering a security breach without a response plan leads to slow, chaotic, and incomplete remediation. Define the incident response procedure — including credential rotation, user notification, logging requirements, and regulatory reporting obligations — before the system goes live.

6.12 What’s Next

After completing these authentication and access control labs, continue with:

If you want to… Read this
Start the fundamental authentication lab Lab: Auth & Access Control Fundamentals
Learn cryptographic foundations Encryption Principles and Crypto Basics
Apply zero trust principles Zero Trust Security
Understand attacker perspectives Threat Modelling and Mitigation
Study authentication methods in depth Authentication Methods for IoT
In 60 Seconds

This hands-on authentication and access control module progresses from concepts through fundamental lab to advanced capability-based systems — building the practical security engineering skills needed to design, implement, and test production-grade IoT authentication that withstands real-world attacks.