Xu hướng IoT Security: Một baseline thực tế cho thiết bị kết nối

IoT security đang được nhắc đến rất nhiều, nhưng đôi khi cách nói làm nó giống một gói tính năng mua thêm: bật TLS, đổi password mặc định rồi xem như xong. Thực tế, một sản phẩm IoT là cả chuỗi gồm thiết bị, firmware, app, API, cloud và quy trình cập nhật. Chỉ cần một mắt xích dùng chung credential hoặc không thể vá lỗi, phần còn lại cũng khó cứu.

Trong bài này, mình chia sẻ một security baseline đủ thực dụng cho thiết bị ESP32-class. Đây không phải checklist compliance và cũng không biến một cảm biến nhiệt độ thành hệ thống ngân hàng. Mục tiêu là giúp bạn biết nên làm gì trước, vì sao cần làm và kiểm tra nó ra sao.

Mình thích vẽ cả đường đi từ thiết bị đến router và cloud trước. Nhìn đủ hệ thống thường phát hiện rủi ro nhanh hơn việc chỉ rà từng hàm mã hóa trong firmware.

Vì sao đây là một xu hướng đáng quan tâm

Thiết bị IoT thường sống lâu hơn app điện thoại đi kèm nó. Nó nằm trong nhà, văn phòng hoặc xưởng nhiều năm, kết nối đều đặn và có thể giữ Wi-Fi credentials, token, dữ liệu cảm biến hoặc quyền điều khiển actuator.

NIST IR 8259 Rev. 1, phát hành năm 2026, tiếp tục đặt trọng tâm vào các hoạt động bảo mật từ trước khi sản phẩm được bán. Baseline kỹ thuật của NIST IR 8259A cũng nhìn thiết bị theo các năng lực như nhận dạng, cấu hình có kiểm soát, bảo vệ dữ liệu, hạn chế interface, cập nhật phần mềm và báo trạng thái bảo mật.

Điểm mình thấy quan trọng nhất: security là khả năng vận hành suốt vòng đời, không chỉ là chọn thuật toán mã hóa vào ngày ship firmware đầu tiên.

Threat model một trang là đủ để bắt đầu

Bạn chưa cần một tài liệu 40 trang. Với cảm biến chất lượng không khí gửi dữ liệu lên cloud, mình viết bốn cột:

Câu hỏi	Ví dụ
Cần bảo vệ gì?	Wi-Fi credential, device key, firmware, dữ liệu phòng
Ai có thể tấn công?	Người cùng mạng, người cầm được thiết bị, account bị chiếm
Họ đi vào từ đâu?	API, BLE/Wi-Fi, OTA URL, UART/JTAG, flash ngoài
Hậu quả là gì?	Giả dữ liệu, chiếm điều khiển, vào mạng nội bộ, brick thiết bị

Sau đó, xếp hạng bằng hai biến đơn giản: mức ảnh hưởng và khả năng xảy ra. Cổng UART lộ log có thể chấp nhận trên board hobby; cùng cổng đó trên khóa cửa thương mại là câu chuyện khác. Threat model giúp bạn dùng công sức đúng chỗ thay vì bật mọi option “secure” mà không hiểu rủi ro.

Baseline mình thường dùng

Lớp	Baseline tối thiểu
Danh tính	ID và credential riêng cho từng thiết bị
Boot	Chỉ chạy firmware được ký bởi khóa tin cậy
Lưu trữ	Bảo vệ key/token ở flash; không hard-code trong source
Kết nối	TLS có kiểm tra certificate và hostname
Quyền	Backend giới hạn đúng thiết bị, user và action
Update	Image có chữ ký, A/B partition, rollback và policy phiên bản
Vòng đời	Factory reset, revoke, log sự kiện, vá lỗi và kế hoạch end-of-life

Không phải thiết bị nào cũng cần cùng một mức. Nhưng nếu một mục bị bỏ, mình muốn đó là quyết định có lý do chứ không phải vì team quên.

1. Mỗi thiết bị cần một danh tính riêng

Sai lầm nguy hiểm nhất là để cả lô sản phẩm dùng chung một API key trong firmware. Khi một board bị đọc flash hoặc log làm lộ key, kẻ tấn công có credentials của cả fleet.

Flow provisioning tốt hơn:

1. Mỗi thiết bị có một device_id không trùng.
2. Tạo key hoặc certificate riêng trong lúc sản xuất/onboarding.
3. Backend gắn danh tính đó với đúng account và phạm vi quyền.
4. Có thể revoke riêng một thiết bị bị mất hoặc nghi lộ key.
5. Log provisioning không bao giờ in private key hay token đầy đủ.

Nếu phần cứng hỗ trợ eFuse, HMAC peripheral, secure element hoặc key manager, hãy giữ key dài hạn ở nơi ứng dụng không cần đọc ra dạng plaintext. ESP-IDF có example NVS Encryption dùng HMAC, trong đó encryption key được derive từ HMAC key trong eFuse thay vì lưu trực tiếp trên flash.

Danh tính riêng theo từng thiết bị giúp thu hồi một node bị lộ mà không phải thay credential của toàn bộ sản phẩm.

2. Secure Boot và Flash Encryption giải hai việc khác nhau

• Secure Boot xác minh chữ ký để ngăn firmware không được phép chạy.
• Flash Encryption làm nội dung flash ngoài khó đọc trực tiếp hơn khi bị tiếp cận vật lý.

Chỉ mã hóa flash không chứng minh firmware là của bạn. Chỉ Secure Boot cũng không nhằm che credential khỏi việc đọc dữ liệu lưu trữ. Tài liệu Secure Boot V2 của ESP-IDF khuyến nghị dùng hai tính năng cùng nhau vì chúng bảo vệ các phần khác nhau của chain of trust.

Ba nguyên tắc vận hành còn quan trọng hơn việc tick menuconfig:

• Khóa ký production không nằm trong repo, CI log hoặc laptop dùng hằng ngày.
• Dev và production dùng key, cấu hình debug và quy trình flash khác nhau.
• Backup key phải được kiểm soát; mất signing key có thể khiến bạn không cập nhật được fleet, còn lộ key có thể làm mất niềm tin của cả chain.

3. TLS chưa đủ nếu authorization yếu

TLS bảo vệ dữ liệu trên đường truyền khi certificate và hostname được kiểm tra đúng. Nó không tự trả lời thiết bị A có được sửa cấu hình của thiết bị B hay không.

Ở API, mình kiểm tra tối thiểu:

• Device credential chỉ truy cập resource của chính device đó.
• User phải có quan hệ sở hữu hoặc quyền rõ ràng trước mỗi action.
• Lệnh nhạy cảm có timestamp/nonce hoặc transaction ID để hạn chế replay.
• Endpoint onboarding và reset có rate limit.
• Firmware không có nhánh “tạm thời” bỏ certificate verification khi gặp lỗi thời gian.

Đừng log Authorization header, Wi-Fi password hay toàn bộ payload chứa token. Log nên đủ để điều tra — device ID, event type, result, firmware version — nhưng không trở thành kho secret thứ hai.

4. OTA an toàn phải xử lý cả image xấu lẫn image lỗi

HTTPS bảo vệ quá trình tải, còn chữ ký firmware xác thực image. Hai lớp này không thay thế nhau. Một OTA flow dễ sống nên có:

download -> verify signature -> write inactive slot -> reboot
         -> health check -> mark valid
         -> failed health check => rollback

Rollback cứu thiết bị khi firmware mới hợp lệ về chữ ký nhưng crash hoặc mất kết nối. Anti-rollback lại ngăn quay về một bản cũ đã biết có lỗ hổng. Hai cơ chế có vẻ ngược nhau, nên policy phải rõ: cho rollback trong cửa sổ xác nhận bản mới; chỉ nâng minimum security version sau khi release đã được kiểm chứng.

ESP-IDF OTA examples có CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE và bước xác nhận image hoạt động. Mình test ít nhất bốn tình huống:

• Cắt nguồn giữa lúc download và giữa lúc ghi partition.
• Server trả image sai chữ ký hoặc sai target chip.
• Firmware mới boot nhưng không kết nối được mạng.
• Backend trả lại version cũ hơn policy cho phép.

Một flow OTA chỉ đáng tin sau khi đã thử cắt nguồn, gửi image sai chữ ký và mô phỏng firmware mới không boot được.

5. Khóa interface debug theo threat model

UART, JTAG, bootloader download mode và test pad giúp phát triển rất nhanh. Chúng cũng là đường vào trực tiếp khi thiết bị nằm trong tay người khác.

Trước production, hãy quyết định rõ:

• UART còn mở không và log có secret hay thông tin nhạy cảm không?
• JTAG bị disable, khóa hay chỉ cho re-enable bằng flow RMA có xác thực?
• Bootloader có nhận image tùy ý qua cổng vật lý không?
• Factory reset xóa Wi-Fi credentials, token, bond và liên kết account đến mức nào?

“Disable hết” không phải lúc nào cũng đúng vì team còn cần bảo hành và phân tích lỗi. Cách tốt hơn là thiết kế RMA có chủ đích, ghi lại trạng thái thiết bị và giới hạn ai có thể mở lại quyền debug.

6. Thu ít dữ liệu hơn cũng là một biện pháp security

Nếu sản phẩm không cần lịch sử chi tiết, đừng thu nó “để sau này biết đâu dùng”. Data không được lưu thì không thể bị lộ từ database của bạn.

Mình thường hỏi:

• Có cần gửi raw sample hay chỉ cần giá trị tổng hợp?
• Device log cần tồn tại bao lâu?
• Serial number có cần xuất hiện trong BLE advertising hoặc mDNS không?
• Khi xóa account, mapping, token và dữ liệu thiết bị nào phải bị xóa theo?

Privacy và security gặp nhau ở đây: giảm dữ liệu cũng giảm blast radius.

Checklist kiểm thử trước khi gọi là “secure”

Dùng các nhóm của OWASP ISTG, mình chạy một vòng thực dụng:

• Dump flash từ một board và tìm SSID, password, token, private key dạng plaintext.
• Mở UART/JTAG/test pad và xem một người có thiết bị trong tay làm được gì.
• Proxy traffic để kiểm tra TLS, certificate validation và secret trong request/log.
• Replay command cũ, đổi device ID và thử truy cập resource của node khác.
• Nạp firmware không ký, firmware ký sai key và version bị chặn bởi policy.
• Cắt nguồn lặp lại trong OTA; xác nhận thiết bị boot lại partition cũ.
• Factory reset rồi kiểm tra credential, bond và quyền trên backend đã thực sự mất.
• Ghi lại phiên bản dependency và ai nhận cảnh báo lỗ hổng sau khi sản phẩm đã bán.

Một test không có bằng chứng cũng dễ bị quên. Hãy lưu command, firmware hash, kết quả mong đợi và kết quả thật trong repo test nội bộ.

Những lỗi mình sẽ sửa trước

Nếu dự án đã chạy nhưng chưa có security plan, mình ưu tiên theo thứ tự:

1. Xóa password mặc định và shared fleet credential.
2. Bắt buộc TLS đúng cách, sửa authorization ở backend.
3. Làm OTA có chữ ký và rollback để còn khả năng vá những lỗi tiếp theo.
4. Bảo vệ credential ở flash, rồi bật chain of trust phù hợp cho production.
5. Khóa debug interface và hoàn thiện factory reset/RMA.
6. Tạo quy trình nhận, phân loại và phát hành bản vá bảo mật.

Đây không phải thứ tự tuyệt đối; threat model có thể đẩy một mục lên trước. Nhưng OTA thường đáng làm sớm vì một thiết bị không thể cập nhật sẽ đóng băng mọi quyết định security của hôm nay.

Kết luận

Xu hướng đáng chú ý nhất của IoT security không phải là một thuật toán mới. Đó là việc bảo mật đang dịch từ “tính năng trong firmware” sang năng lực của cả sản phẩm trong suốt vòng đời.

Bạn có thể bắt đầu khá nhỏ: một threat model một trang, credential riêng cho từng thiết bị, API có authorization, firmware được ký, OTA có rollback và một buổi test theo OWASP ISTG. Làm chắc sáu việc đó hữu ích hơn nhiều so với việc thêm một biểu tượng ổ khóa vào dashboard.

Nguồn tham khảo

• OWASP IoT Security Testing Guide
• ESP-IDF security examples
• ESP-IDF OTA examples
• NIST IR 8259A — IoT Device Cybersecurity Capability Core Baseline
• NIST IR 8259 Rev. 1 — Foundational Cybersecurity Activities