Giải pháp bảo mật kết nối các thiết bị IoT với đám mây

　　Mặc dù mọi người ngày càng nhận thức được nhu cầu bảo mật, nhưng các nhà phát triển thường thấy mình đi tắt để kết nối các thiết bị IoT với đám mây. Trong nhiều trường hợp, xung đột giữa sự phức tạp của các cơ chế an toàn thích hợp, bộ nhớ hạn chế và tài nguyên xử lý có sẵn trong các thiết bị IoT chạy bằng pin siêu nhỏ và nhu cầu vận chuyển sản phẩm dường như không thể vượt qua.

　　Để giải quyết những vấn đề này và đơn giản hóa việc triển khai các tính năng bảo mật trong các thiết bị IoT, Microchip Technology và Google đã hợp tác để tạo ra một phương pháp kết hợp các tính năng phần cứng bảo mật của Microchip với cấu trúc dữ liệu đơn giản được gọi là JSON Web Token (JWT). Kết quả là một cách đơn giản để đảm bảo xác thực lẫn nhau giữa các thiết bị IoT và các dịch vụ cốt lõi của Google Cloud IoT.

　　Bài viết này sẽ giới thiệu các mối đe dọa bảo mật đối với các thiết bị IoT và trình bày các thiết bị hiện đang được sử dụng để giải quyết các mối đe dọa này. Nó sẽ xác định các lỗ hổng bảo mật và cách các nhà phát triển và nhà thiết kế hệ thống nhúng sử dụng JWT để tắt chúng.

　　Lỗ hổng bảo mật trong thiết bị IoT

　　Các cuộc tấn công vào thiết bị IoT có thể có nhiều hình thức và không giới hạn ở việc triển khai IoT quy mô lớn. Đối với các tin tặc muốn khai thác tài nguyên từ nhiều thiết bị riêng lẻ trong các mạng botnet được sử dụng cho các cuộc tấn công từ chối dịch vụ phân tán (DDoS), ngay cả IoT nhỏ nhất cũng là một mục tiêu hấp dẫn. Do đó, các nhà thiết kế của mọi loại thiết bị IoT chắc chắn cần bảo vệ hệ thống của họ thông qua các cơ chế bảo mật dựa trên phần cứng mạnh mẽ để ngăn chặn các cuộc tấn công.

　　Ví dụ: sử dụng bộ nhớ hệ thống hoặc bộ nhớ flash để lưu trữ khóa riêng tư để mã hóa và xác thực khiến các thiết bị IoT dễ bị tấn công. Tệ hơn nữa, tin tặc có thể đánh cắp các khóa này và sử dụng chúng để truy cập mạng IoT và các tài nguyên bổ sung của công ty.

　　IC an toàn

　　Các thiết bị bảo mật chuyên dụng như CryptoMemory và CryptoAuthentication IC của Microchip Technology có các chức năng phần cứng dựa trên cơ chế bảo vệ khóa riêng tư và dữ liệu bí mật khác. Các mảng EEPROM được tích hợp vào các thiết bị này, cung cấp các cơ chế bảo mật mã hóa và lưu trữ an toàn chỉ có thể truy cập thông qua giao diện nối tiếp SPI hoặc I2C của thiết bị (xem Hình 1). Do đó, các thiết bị này cung cấp một cách đơn giản để thêm bộ nhớ an toàn và các tính năng bảo mật khác vào bất kỳ thiết kế thiết bị IoT nào.

　　Hình 1: Các thiết bị bảo mật phần cứng của Microchip Technology (chẳng hạn như AT88SC0204C CryptoMemory IC) cung cấp khả năng lưu trữ an toàn và sử dụng các cơ chế mã hóa tích hợp để bảo vệ quyền truy cập vào EEPROM trên chip. (Ảnh: Microchip Technology)

　　Các thành viên của loạt Microchip CryptoAuthentication (chẳng hạn như ATECC608A) tăng cường nền tảng lưu trữ an toàn và hỗ trợ các thuật toán mã hóa thường được sử dụng trong thiết kế bảo mật. Trong số các tính năng phần cứng của nó, thiết bị có tính năng tăng tốc phần cứng cho các thuật toán khác nhau, bao gồm:

　　Thuật toán mã hóa bất đối xứng:

　　FIPS186-3 Thuật toán chữ ký số đường cong elip (ECDSA)

　　FIPS SP800-56A Đường cong elip Diffie-Hellman (ECDH)

　　Mã hóa đường cong elip (ECC) tiêu chuẩn P256 của NIST

　　Thuật toán mã hóa đối xứng:

　　Mã băm SHA-256

　　Mật mã mã xác thực tin nhắn dựa trên băm (HMAC)

　　Mật mã AES-128

　　Mật mã AES-GCM (Galois Field Multiplication)

　　Chức năng dẫn xuất chính (KDF):

　　Hàm giả ngẫu nhiên (PRF) KDF

　　Khai thác dựa trên HMAC - và mở rộng KDF (HKDF)

　　Đối với các chuyên gia tiền điện tử, bộ tính năng mã hóa này đại diện cho một danh sách đầy đủ các cơ chế cần thiết để hỗ trợ các giao thức bảo mật cấp cao hơn. Xác thực và trao đổi dữ liệu an toàn. Ví dụ: tính năng KDF cung cấp các cơ chế cơ bản cần thiết cho các giao thức Bảo mật tầng truyền tải (TLS) để xác minh những người tham gia vào các phiên trao đổi dữ liệu trước khi trao đổi hoặc thậm chí bắt đầu.

　　Trong giao thức này, các phiên TLS gửi yêu cầu từ máy khách đến máy chủ để bắt đầu một phiên bảo mật. Máy chủ phản hồi bằng chứng chỉ kỹ thuật số của nó, mà máy khách sử dụng để xác nhận danh tính của máy chủ. Sau khi máy khách xác minh máy chủ theo cách này, cài đặt phiên tiếp tục tạo khóa phiên bằng khóa công khai của máy chủ để mã hóa một số giá trị ngẫu nhiên được tạo bằng PRF KDF hoặc HDKF mạnh hơn.

　　Giao thức xác thực TLS là nền tảng của bảo mật Internet. Toàn bộ ngành công nghiệp cung cấp chứng chỉ, được gọi là Cơ quan cấp chứng chỉ (CA), đã phát triển thành một thành phần quan trọng hỗ trợ truyền thông an toàn. Công ty có được chứng chỉ đáng tin cậy từ CA để cài đặt trên máy chủ của riêng mình, hỗ trợ giao thức xác thực máy chủ TLS tiêu chuẩn nói trên.

　　Đối với các ứng dụng IoT, các mạng được kết nối rộng rãi và sâu sắc với các công ty và xác thực một chiều như vậy không đủ để đảm bảo bảo vệ. Ví dụ: tin tặc có chứng chỉ gian lận có thể tự giới thiệu mình là máy chủ hợp pháp cho các thiết bị IoT như một phần của cuộc tấn công rộng lớn hơn.

　　Bất chấp rủi ro, các nhà phát triển IoT thường gặp khó khăn trong việc triển khai các giao thức xác thực lẫn nhau TLS vì chứng chỉ, khóa và phần mềm cần thiết để xác thực máy khách bằng TLS có thể vượt quá khả năng của nhiều thiết bị IoT. Thông qua sự hợp tác, Microchip Technology và Google đã tạo ra một cách tiếp cận thay thế kết hợp chức năng ATECC608A với cấu trúc dữ liệu đơn giản được gọi là JSON Web Token (JWT). Kết quả là một cách đơn giản để đảm bảo xác thực lẫn nhau giữa các thiết bị IoT và các dịch vụ cốt lõi của Google Cloud IoT.

　　Xác thực dựa trên JWT

　　RFC 7519 quy định rằng JWT là một vùng chứa tiêu chuẩn công nghiệp cho thông tin về thực thể chuẩn bị và truyền JWT, được gọi là yêu cầu. Bản thân cấu trúc JWT bao gồm ba phần:

　　Tiêu đề, bao gồm cả tên JSON: tên của thuật toán mật mã ("alg") (ví dụ: "EC256" của ECDSA sử dụng đường cong NIST P-256) để ký mã thông báo và các loại mã thông báo ("typ") ("JWT" của các mã thông báo này)

　　Tải trọng, bao gồm tên JSON: cặp giá trị cho mỗi yêu cầu

　　Chữ ký: Nó sử dụng thuật toán được chỉ định trong tiêu đề để mã hóa khóa, tiêu đề và bộ khai báo, mỗi bộ được chuyển đổi riêng lẻ thành mã hóa URL base64 trước khi mã hóa

　　RFC 7519 mang lại sự linh hoạt tuyệt vời để chỉ định các yêu cầu trong tải trọng hoặc các bộ phận khác. Tiêu chuẩn thậm chí còn cho phép các JWT không an toàn được tạo ra mà không có chữ ký hoặc mã hóa, trong trường hợp đó tiêu đề sẽ bao gồm tên của thuật toán: cặp giá trị {{alg":"none"}. Đối với JWT được sử dụng với các dịch vụ cốt lõi của Google Cloud IoT, Google cần một phần chữ ký và một payload chứa ba khai báo bắt buộc, bao gồm:

　　"iat" - "Thời gian phát hành" khi tạo mã thông báo ở định dạng dấu thời gian ISO 8601 UTC, số giây kể từ 1970-01-01T00:00:00Z (ví dụ: 1561896000 12:00 GMT vào ngày 30 tháng 6 năm 2019)

　　"exp" - Dấu thời gian UTC chỉ định thời gian hết hạn token, tối đa 24 giờ vượt quá giá trị "IAT" cộng với thời gian gia hạn 10 phút, để giải quyết các sai lệch đồng hồ hệ thống khác nhau giữa máy khách và máy chủ (ví dụ: ngày 1 tháng 7 năm 2019 1561982400, GMT 00:00 00:00)

　　"aud" - một chuỗi chứa mã dự án Google Cloud của nhà phát triển

　　< p> giải pháp xác thực thiết bị IoT của Google kết hợp xác thực máy chủ dựa trên TLS thông thường với JWT được tạo bằng các khai báo tương đối đơn giản này để xác thực thiết bị IoT. Để bắt đầu một phiên mới, thiết bị IoT mở một ổ cắm an toàn cho máy chủ và xác thực máy chủ bằng cùng một giao thức TLS được mô tả trước đó.

　　Bước tiếp theo trong quy trình này dựa vào giao thức truyền dữ liệu từ xa hàng đợi tin nhắn nhẹ (MQTT) của Google IoT Cloud cho các giao dịch mạng IoT. Sử dụng một ổ cắm an toàn cho một máy chủ được xác thực, thiết bị IoT sử dụng JWT duy nhất của nó làm mật khẩu đăng nhập để "đăng nhập" vào dịch vụ máy chủ MQTT trên máy chủ đó (Khoảng không quảng cáo 1).

　　Mặc dù các thiết bị IoT gửi tên người dùng như một phần của trình tự đăng nhập này, nhưng tên người dùng không được sử dụng để xác thực. Do đó, một tên người dùng ảo (Liệt kê 2) đã được chuyển. Thay vào đó, xác thực thiết bị IoT dựa trên JWT được gửi dưới dạng mật khẩu đăng nhập. Vì chữ ký JWT là sự kết hợp của tiêu đề, tải trọng và khóa riêng tư của thiết bị, nên các dịch vụ cốt lõi của Google Cloud IoT có thể xác minh xem JWT có thực sự đến từ các thiết bị được ủy quyền hay không. Để xác minh này, Dịch vụ Google Cloud IoT sử dụng các khóa công khai của thiết bị trước đây được các nhà phát triển thiết bị IoT lưu trữ trong Google Cloud bằng cách sử dụng quy trình quản lý khóa được mô tả bên dưới. So với việc chỉ sử dụng TLS, cách tiếp cận này cung cấp xác thực lẫn nhau thông qua cách tiếp cận kết hợp, tăng tốc các quy trình đồng thời giảm yêu cầu tài nguyên cho các thiết bị IoT.

　　Các yếu tố hỗ trợ chính

　　ATECC608A và chức năng của chuỗi cung ứng là động lực chính của cách tiếp cận này. Mặc dù bất kỳ MCU nào cuối cùng cũng có thể tạo ra chữ ký mã hóa được mã hóa từ tiêu đề và tải trọng JWT, nhưng bất kỳ phương pháp chỉ sử dụng phần mềm nào vẫn dễ bị tấn công nếu không có lưu trữ khóa bảo mật dựa trên phần cứng. Ngoài ra, đối với nhiều thiết bị hoặc ứng dụng IoT hạn chế tài nguyên với yêu cầu nghiêm ngặt về thời gian phản hồi, tải bộ xử lý và độ trễ thực thi cần thiết để triển khai "chỉ phần mềm" có thể bị cấm. Cuối cùng, nếu không có các thuật toán bảo mật mở rộng và kinh nghiệm giao thức nâng cao hơn, các nhà phát triển sẽ khó triển khai các chức năng phần mềm cần thiết. Microchip giải quyết những vấn đề này thông qua thư viện CryptoAuthLib của nó (Hình 2).

　　Hình 2: Bởi vì CryptoAuthLib sử dụng lớp trừu tượng phần cứng (HAL) để tách các chức năng API và nguyên thủy cốt lõi khỏi phần cứng cơ bản, các nhà phát triển có thể định vị phần mềm của họ cho các thiết bị hỗ trợ khác nhau. (Ảnh: Microchip Technology)

　　Microchip CryptoAuthLib đơn giản hóa việc triển khai các tính năng IoT an toàn, chẳng hạn như giao thức xác thực Google JWT, giảm các hoạt động bảo mật phức tạp thành một tập hợp các lệnh gọi hàm được cung cấp thông qua giao diện lập trình ứng dụng (API) CryptoAuthLib. Đối với các nhà phát triển IoT, có lẽ quan trọng nhất là tính năng cốt lõi Microchip CryptoAuthLib tận dụng đầy đủ các IC mã hóa Microchip như ATECC608A để tăng tốc độ thực hiện các tính năng bảo mật trong thiết kế. Ví dụ, trong Liệt kê 1, một lệnh gọi đến atca_jwt_finalize() sử dụng các thiết bị mã hóa có sẵn (chẳng hạn như ATECC608A) để tạo ra một JWT cho mật khẩu trong Liệt kê 2. Trong trường hợp này, ATECC608A tăng tốc độ mã hóa chữ ký JWT, hãy đọc thiết kế từ khóa lưu trữ an toàn tích hợp của nó để hoàn tất quá trình tạo chữ ký được mô tả trước đó.

　　Tuy nhiên, ngay cả với phần mềm và thiết bị bảo mật phức tạp, các thiết bị IoT vẫn dễ bị tấn công do các phương pháp quản lý khóa và chứng chỉ truyền thống. Trước đây, khóa riêng tư phải được tạo ra bên ngoài và tải vào các thiết bị lưu trữ an toàn trong quá trình sản xuất, phân phối hoặc thậm chí triển khai. Ngay cả khi sử dụng các mô-đun bảo mật phần cứng và cơ sở bảo mật, các bí mật tồn tại trong thời gian ngắn ngoài thiết bị duy nhất "cần biết" chúng đại diện cho các lỗ hổng bảo mật có thể vô tình hoặc cố ý bị lộ. Bằng cách tận dụng khả năng ATECC608A, Microchip và Google đã loại bỏ phần lớn các lỗ hổng bảo mật truyền thống.

　　Trong cách tiếp cận mới này, Microchip sử dụng khả năng của ATECC608A để tạo ra các cặp khóa mà không cần rời khỏi thiết bị với khóa riêng tư (Hình 3). Sau đó, Microchip sử dụng chứng chỉ trung gian để ký khóa công khai do thiết bị tạo ra, được cung cấp bởi khách hàng và được lưu trữ trên một máy chủ an toàn trong các cơ sở bảo mật của Microchip. Cuối cùng, Microchip truyền khóa công khai một cách an toàn đến tài khoản khách hàng trong Trình quản lý thiết bị Google Cloud IoT, có thể lưu trữ tối đa ba khóa công khai trên mỗi thiết bị để hỗ trợ các chính sách xoay vòng khóa. Sau khi triển khai, các thiết bị IoT có thể sử dụng các tính năng bảo mật ATECC608A để tạo JWT được sử dụng trong quy trình xác thực lẫn nhau được mô tả trước đó.

　　Hình 3: Sự kết hợp giữa Microchip Technology và các dịch vụ Google Cloud IoT giúp đơn giản hóa cấu hình khóa và chứng chỉ, cung cấp một cơ chế được bảo vệ nhằm tăng cường bảo mật ứng dụng IoT. (Ảnh: Google)

　　Sự hợp tác này giữa Microchip và Google cho phép các nhà phát triển giảm tải hoàn toàn quy trình quản lý khóa quan trọng này. Đối với các yêu cầu tùy chỉnh, các nhà phát triển có thể sử dụng hàm API CryptoAuthLib atcab_genkey() để triển khai quy trình quản lý khóa của riêng họ, dẫn đến ATECC608A tạo các cặp khóa, lưu trữ khóa riêng tư trong bộ nhớ an toàn của họ và trả về khóa công khai được liên kết. /p>

　　Để khám phá việc tạo khóa và các tính năng bảo mật ATECC608A khác, các nhà phát triển có thể nhanh chóng xây dựng một môi trường phát triển toàn diện được xây dựng xung quanh bộ đánh giá Microchip SAM D21 Xplained Pro. Dựa trên Microchip ATSAMD21J18A 32-bit Arm ® Cortex-M0 ® + MCU, bộ SAM D21 Xplained Pro cung cấp trình điều khiển nền tảng phần cứng hoàn chỉnh và mô-đun mã được hỗ trợ bởi Khung phần mềm nâng cao (ASF) của Microchip.

　　Để đánh giá các thiết bị CryptoAuthentication, bao gồm cả ATECC608A, các nhà phát triển có thể chỉ cần chèn bo mạch bổ sung CryptoAuth XPRO-B vào một trong hai đầu mở rộng của bo mạch Xplained Pro. Microchip cung cấp phần mềm ví dụ để đánh giá các tính năng bảo mật của CryptoAuthLib và ATECC608A. Hơn nữa, các nhà phát triển có thể chèn bo mạch bổ sung Wi-Fi Microchip ATWINC1500-XPRO vào một tiêu đề khác để chạy phần mềm mẫu Microchip, phần mềm này thể hiện quy trình xác thực lẫn nhau được mô tả trong bài viết này, bao gồm xác thực máy chủ TLS và xác thực thiết bị JWT.

　　Kết luận

　　Mặc dù bảo mật ứng dụng IoT mang lại nhiều yêu cầu, nhưng thách thức chính thường nằm ở việc triển khai xác thực lẫn nhau cho các thiết bị IoT và tài nguyên đám mây. Trong các hệ thống IoT hạn chế tài nguyên, các giao thức truyền thống có thể vượt quá bộ nhớ và tài nguyên xử lý có sẵn. Sử dụng thư viện CryptoAuthLib của Microchip Technology và ATECC608A CryptoAuthentication IC, các nhà phát triển có thể triển khai cách tiếp cận hiệu quả hơn dựa trên Mã thông báo web JSON để kết nối an toàn các thiết bị IoT với các dịch vụ Google Cloud IoT.