Bản thân tác vụ ủy quyền có thể được mô tả tốt nhất là cấp quyền truy cập cho máy của người dùng yêu cầu đối với tài nguyên được lưu trữ trên thiết bị, tức là máy chủ tài nguyên. Trao đổi này được trung gian bởi một hoặc nhiều máy chủ ủy quyền (authorization servers - ASes). Quản lý ủy quyền cho một số lượng lớn thiết bị và người dùng có thể là một nhiệm vụ phức tạp và vì vậy các tiêu chuẩn cũng cần đạt được mức độ hiệu quả ít chậm trễ nhất.

Bước sang một lĩnh vực mới, nếu việc ủy quyền thông thường trên môi trường mạng khá ổn định thì việc ủy quyền đối với môi trường Internet of Things (IoT) lại không đơn giản như vậy. Nếu các thiết bị IoT được xây dựng theo xu hướng nhỏ gọn, đa nhiệm thì vấn đề bộ nhớ sẽ luôn là vấn đề. Nếu mạng thiết bị IoT được xây dựng để trao đổi dữ liệu liên tục thì việc xác thực truy cập bắt buộc sẽ rất mất thời gian. Những vấn đề này hoàn toàn khác với việc ủy quyền xác thực thông thường.

Và để giải quyết vấn đề này, nhóm nghiên cứu của Lực lượng đặc nhiệm kỹ thuật Internet (IETF) đã xây dựng một bộ tiêu chuẩn mới cho phép ủy quyền xác thực ở môi trường bị ràng buộc (Authentication and Authorization for Constrained Environments (ACE)) với khung tiêu chuẩn OAuth 2.0. Tiêu chuẩn này được công bố tháng 8 năm 2022 với mã số là RFC 9200.

Tổng quan tiêu chuẩn ACE-OAuth 2.0

Tiêu chuẩn ACE-OAuth 2.0 xác định khuôn khổ ACE để ủy quyền trong môi trường IoT. Tiêu chuẩn bao gồm một khối cơ bản và 3 khối giải thuật khác giúp xây dựng và hoàn thiện việc kết nối, ủy quyền và xác thực này.

Khối cơ bản là khung OAuth 2.0 (RFC 6749), khung này được triển khai rộng rãi. Nhiều thiết bị IoT có thể hỗ trợ OAuth 2.0 mà không cần bất kỳ tiện ích mở rộng bổ sung nào, nhưng đối với một số cài đặt hạn chế nhất định, cần phải lập hồ sơ bổ sung.

Một khối giải thuật đầu tiên là giao thức truyền tải web nhẹ CoAP (RFC 7252) dành cho những môi trường giao tiếp mà HTTP không thích hợp, CoAP là một giao thức trao đổi thông tin chuyên biệt để sử dụng với các nút bị ràng buộc và mạng bị hạn chế trong IoT. CoAP thường chạy trên UDP, điều này làm giảm thêm chi phí và trao đổi tin nhắn. Mặc dù thông số kỹ thuật này xác định các tiện ích mở rộng để sử dụng OAuth qua CoAP, các giao thức cơ bản khác không bị cấm hỗ trợ trong tương lai, chẳng hạn như HTTP/2, Truyền tải từ xa xếp hàng (MQTT), Bluetooth Low Năng lượng (BLE) và QUIC (RFC9000). Các kỹ thuật trao đổi thông tin được xây dựng trong giao thức theo tác động từ RESTful, chẳng hạn như GET và POST.

Khối giải thuật thứ hai là Biểu diễn đối tượng nhị phân ngắn gọn (CBOR Object Signing and Encryption (CBOR)) (RFC 8949), dành cho các mã hóa mà JSON không đủ nhỏ gọn. CBOR là một bảng mã nhị phân được thiết kế cho mã và kích thước tin nhắn nhỏ. Mã thông báo độc lập và trọng tải thông điệp giao thức được mã hóa trong CBOR khi CoAP được sử dụng. Ngay cả khi giao thức CoAP không được sử dụng, việc sử dụng CBOR vẫn được khuyến nghị áp dụng.

Khối giải thuật thứ ba là Mã hóa và ký đối tượng CBOR (CBOR Object Signing and Encryption (COSE)) (RFC8152), cho phép bảo mật lớp đối tượng như một giải pháp thay thế hoặc bổ sung cho bảo mật lớp truyền tải (DTLS (RFC6347) (RFC9147) hoặc TLS (RFC8446)). COSE được sử dụng để bảo mật các mã thông báo độc lập, chẳng hạn như mã thông báo bằng chứng sở hữu (PoP), là một phần mở rộng cho các mã thông báo mang OAuth. Định dạng mã thông báo mặc định được xác định trong Mã thông báo web CBOR (CBOR Web Token (CWT)) (RFC8392). Bảo mật lớp ứng dụng cho CoAP bằng COSE có thể được cung cấp với Bảo mật đối tượng cho Môi trường RESTful bị ràng buộc (Object Security for Constrained RESTful Environments - (OSCORE)) (RFC8613).

Tuy nhiên trên thị trường hiện nay thì không phải mọi thiết bị IoT đều gặp phải tất cả các ràng buộc. Tuy nhiên, khuôn khổ ACE xem xét tất cả các khía cạnh này và cho phép một số biến thể triển khai khác nhau cùng tồn tại, thay vì bắt buộc một giải pháp phù hợp với tất cả. Điều quan trọng là phải đề cập đến phạm vi rộng các trường hợp sử dụng liên kết có thể có và các yêu cầu khác nhau theo quan điểm bảo mật. Sau khi triển khai IoT một cách ổn định, các biến thể triển khai phổ biến sẽ được ghi lại dưới dạng hồ sơ ACE.

Một số triển khai OAuth 2.0 tại tiêu chuẩn xác thực này

Khung ủy quyền OAuth 2.0 cho phép người dùng có được quyền truy cập theo phạm vi vào tài nguyên với sự cho phép của chủ sở hữu tài nguyên. Thông tin ủy quyền hoặc các tham chiếu đến nó, được chuyển giữa các nút bằng cách sử dụng mã thông báo truy cập. Các mã thông báo truy cập này được cấp cho người dùng bởi một máy chủ ủy quyền với sự chấp thuận của chủ sở hữu tài nguyên. Máy của người dùng sử dụng mã thông báo truy cập để truy cập các tài nguyên được bảo vệ do máy chủ tài nguyên lưu trữ.

Một số thuật ngữ OAuth 2.0 được sử dụng trong đặc điểm kỹ thuật này:

- Mã thông báo truy cập (Access Tokens): Mã thông báo truy cập là thông tin xác thực cần thiết để truy cập các tài nguyên được bảo vệ.

- “Introspection”: Là một phương pháp để máy chủ tài nguyên, hoặc có thể là một máy của người dùng truy vấn máy chủ ủy quyền về trạng thái hoạt động và nội dung của mã thông báo truy cập đã nhận. Điều này đặc biệt hữu ích trong những trường hợp quyết định ủy quyền rất năng động và/hoặc khi bản thân mã thông báo truy cập nhận được là một tham chiếu không rõ ràng, thay vì mã thông báo độc lập.

- Làm mới mã thông báo (Refresh Tokens): Là thông tin xác thực được sử dụng để lấy mã thông báo truy cập. Mã thông báo làm mới được máy chủ ủy quyền cấp cho máy của người dùng và được sử dụng để lấy mã thông báo truy cập mới khi mã thông báo truy cập hiện tại hết hạn hoặc để lấy mã thông báo truy cập bổ sung có phạm vi giống hệt hoặc hẹp hơn (mã thông báo truy cập như vậy có thể có thời gian tồn tại ngắn hơn và ít quyền hơn được ủy quyền bởi chủ sở hữu tài nguyên). Việc cấp mã thông báo làm mới là tùy chọn theo quyết định của máy chủ ủy quyền. Nếu máy chủ ủy quyền phát hành mã thông báo làm mới. Mã thông báo làm mới trong OAuth 2.0 là một chuỗi đại diện cho ủy quyền được cấp cho máy của người dùng bởi chủ sở hữu tài nguyên. Chuỗi thường không rõ ràng đối với người dùng. Mã thông báo biểu thị một số nhận dạng được sử dụng để truy xuất thông tin ủy quyền. Không giống như mã thông báo truy cập, mã làm mới chỉ được sử dụng với máy chủ ủy quyền và không bao giờ được gửi đến máy chủ tài nguyên. Trong khuôn khổ của tiêu chuẩn này, mã làm mới được mã hóa ở dạng nhị phân thay vì chuỗi, nếu được sử dụng.

- Mã thông báo bằng chứng sở hữu (Proof-of-Possession Tokens): Mã thông báo có thể được liên kết với một khóa mật mã, sau đó được sử dụng để liên kết mã thông báo với một yêu cầu được cấp phép bởi mã thông báo. Các mã thông báo như vậy được gọi là mã thông báo bằng chứng sở hữu (hoặc mã thông báo PoP).

Khái niệm bảo mật bằng chứng sở hữu được sử dụng ở đây giả định rằng máy chủ ủy quyền hoạt động như một bên thứ ba đáng tin cậy liên kết khóa với mã thông báo. Trong trường hợp mã thông báo truy cập, những cái gọi là khóa PoP này sau đó được máy của người dùng sử dụng để chứng minh quyền sở hữu bí mật đối với máy chủ chứa tài nguyên khi truy cập tài nguyên. Máy chủ chứa tài nguyên khi nhận được mã thông báo truy cập, cần xác minh rằng khóa được khách hàng sử dụng khớp với khóa được liên kết với mã thông báo truy cập. Khi đặc tả này sử dụng thuật ngữ "mã thông báo truy cập", nó được giả định là mã thông báo truy cập PoP trừ khi có quy định cụ thể khác. Khóa liên kết với mã thông báo (khóa PoP) có thể sử dụng mật mã đối xứng hoặc không đối xứng. Việc lựa chọn loại mật mã phù hợp phụ thuộc vào các ràng buộc của thiết bị IoT cũng như các yêu cầu bảo mật của trường hợp sử dụng. Mã thông báo là một tham chiếu đơn giản hoặc một đối tượng thông tin có cấu trúc (ví dụ: CWT (RFC8392)) được bảo vệ bởi trình bao bọc mật mã (ví dụ: COSE (RFC8152)). Việc lựa chọn khóa PoP không nhất thiết ngụ ý một loại thông tin xác thực cụ thể để bảo vệ tính toàn vẹn của mã thông báo.

+ Khóa PoP đối xứng: máy chủ ủy quyền tạo một khóa PoP đối xứng, ngẫu nhiên. Khóa được lưu trữ để được trả lại trong các cuộc gọi “Introspection” hoặc được bao gồm trong mã thông báo. Toàn bộ mã thông báo hoặc chỉ khóa phải được mã hóa trong trường hợp thứ hai. Khóa PoP cũng được trả lại cho máy của người dùng cùng với mã thông báo, được bảo vệ bởi kênh an toàn.

+ Khóa PoP không đối xứng: Một cặp khóa bất đối xứng được tạo bởi máy của người dùng và khóa công khai được gửi đến máy chủ ủy quyền (nếu nó chưa có thông tin về khóa công khai trên máy của người dùng). Thông tin về khóa công khai, là khóa PoP trong trường hợp này, được lưu trữ để trả về khi gọi nội quan hoặc được đưa vào bên trong mã thông báo và được gửi lại cho người dùng. Máy chủ tài nguyên sử dụng mã thông báo có thể xác định khóa công khai từ thông tin trong mã thông báo, cho phép khách hàng sử dụng khóa riêng tương ứng để làm bằng chứng sở hữu.

Mã thông báo là một tham chiếu đơn giản hoặc một đối tượng thông tin có cấu trúc (ví dụ: CWT (RFC8392)) được bảo vệ bởi trình bao bọc mật mã (ví dụ: COSE (RFC8152)). Việc lựa chọn khóa PoP không nhất thiết ngụ ý một loại thông tin xác thực cụ thể để bảo vệ tính toàn vẹn của mã thông báo.

- Phạm vi và Quyền: Trong OAuth 2.0, máy của người dùng chỉ định loại quyền mà ứng dụng đang tìm cách lấy (thông qua tham số) trong yêu cầu mã thông báo truy cập. Đổi lại, máy chủ ủy quyền có thể sử dụng tham số phản hồi để thông báo cho người dùng về phạm vi của mã thông báo truy cập được phát hành. Các giá trị của tham số trong OAuth 2.0 được biểu thị dưới dạng danh sách các chuỗi phân biệt bằng dấu cách, phân biệt chữ hoa chữ thường với ngữ nghĩa mà máy chủ ủy quyền và máy chủ tài nguyên đã biết.

- Thực thể (Claims): Thông tin có trong mã thông báo truy cập hoặc được trả về từ quá trình xem xét “Introspection”, được gọi là xác nhận quyền sở hữu, ở dạng các cặp tên-giá trị. Ví dụ: mã thông báo truy cập có thể bao gồm xác nhận quyền sở hữu xác định AS đã phát hành mã thông báo (thông qua thực thể ‘iss’) và đối tượng mà mã thông báo truy cập dành cho đối tượng (thông qua thực thể ‘aud’). Đối tượng của mã thông báo truy cập có thể là một tài nguyên cụ thể hoặc nhiều máy chủ tài nguyên. Các chính sách của chủ sở hữu tài nguyên ảnh hưởng đến những gì xác nhận quyền sở hữu được máy chủ ủy quyền đưa vào mã thông báo truy cập.

Một số triển khai của CoAP trong ACE-OAuth 2.0

CoAP là một giao thức tầng ứng dụng tương tự như HTTP nhưng được thiết kế đặc biệt cho các môi trường hạn chế hay môi trường bị ràng buộc. CoAP thường sử dụng phương thức truyền dữ liệu theo hướng datagram, chẳng hạn như UDP, và có thể xảy ra sự thay đổi vị trí hoặc thất lạc gói tin. Một giải pháp bảo mật cần phải tính đến các khía cạnh sau.

Trong khi HTTP sử dụng tiêu đề và chuỗi truy vấn để truyền tải thông tin bổ sung về một yêu cầu, CoAP mã hóa thông tin đó thành các tham số tiêu đề được gọi là “tùy chọn”.

CoAP hỗ trợ phân mảnh lớp ứng dụng của tải trọng CoAP thông qua chuyển giao theo khối. Tuy nhiên, chuyển khối có tính toán không làm tăng giới hạn kích thước của các “tùy chọn” CoAP; do đó, dữ liệu được mã hóa trong các tùy chọn phải được giữ ở mức nhỏ.

Bảo mật lớp truyền tải cho CoAP có thể được cung cấp bởi DTLS hoặc TLS. CoAP xác định một số hoạt động proxy yêu cầu kết thúc bảo mật lớp truyền tải tại proxy. Một cách tiếp cận để bảo vệ giao tiếp CoAP end-to-end thông qua proxy và cũng để hỗ trợ bảo mật cho CoAP qua một phương tiện truyền tải khác theo một cách thống nhất, là cung cấp bảo mật ở lớp ứng dụng bằng cách sử dụng cơ chế bảo mật dựa trên đối tượng, chẳng hạn như COSE.

Một ứng dụng của COSE là OSCORE cung cấp tính năng bảo mật từ đầu đến cuối, tính toàn vẹn và bảo vệ phát lại, cũng như ràng buộc an toàn giữa yêu cầu CoAP và thông báo phản hồi. Trong OSCORE, các thông điệp CoAP được bao bọc trong các đối tượng COSE và được gửi bằng CoAP.

Trong khuôn khổ của tiêu chuẩn này, việc sử dụng CoAP thay thế cho HTTP được khuyến nghị để sử dụng trong các môi trường hạn chế. Đối với bảo mật thông tin liên lạc, khuôn khổ này không đưa ra đề xuất giao thức rõ ràng, vì sự lựa chọn phụ thuộc vào các yêu cầu của ứng dụng cụ thể.

Trao đổi thông tin trong ACE-OAuth 2.0

Khung ACE dựa trên các tương tác giao thức OAuth 2.0 sử dụng điểm cuối mã thông báo và tùy chọn điểm cuối nội quan. Một máy của người dùng nhận được mã thông báo truy cập và tùy chọn là mã làm mới, từ một máy chủ ủy quyền bằng cách sử dụng điểm cuối mã thông báo và sau đó trình bày mã thông báo truy cập cho một máy chủ tài nguyên để có quyền truy cập vào tài nguyên được bảo vệ. Trong hầu hết các triển khai, máy chủ tài nguyên có thể xử lý cục bộ mã thông báo truy cập; tuy nhiên, trong một số trường hợp, máy chủ tài nguyên có thể trình bày nó với máy chủ ủy quyền thông qua điểm cuối nội quan để nhận thông tin mới.

Hình 1: Luồng cơ bản của giao thức

Yêu cầu Mã thông báo Truy cập (A):

Máy khách thực hiện yêu cầu mã thông báo truy cập đến điểm cuối mã thông báo tại máy chủ ủy quyền. Khung này giả định việc sử dụng mã thông báo truy cập PoP trong đó máy chủ ủy quyền liên kết khóa với mã thông báo truy cập. Khách hàng có thể bao gồm các quyền mà nó tìm cách có được và thông tin về thông tin xác thực mà nó muốn sử dụng để làm bằng chứng chiếm hữu (ví dụ: mật mã đối xứng/bất đối xứng hoặc tham chiếu đến một khóa cụ thể) của mã thông báo truy cập.

Phản hồi mã thông báo truy cập (B):

Nếu yêu cầu từ khách hàng đã được xác minh, xác thực và ủy quyền thành công, máy chủ ủy quyền sẽ trả về mã thông báo truy cập và tùy chọn là mã thông báo làm mới. Lưu ý rằng chỉ một số loại tài trợ nhất định mới hỗ trợ mã thông báo làm mới. Máy chủ ủy quyền cũng có thể trả về các tham số bổ sung, được gọi là "Thông tin truy cập". Ngoài các tham số phản hồi được xác định bởi OAuth 2.0 và phần mở rộng mã thông báo truy cập PoP, khung này xác định các tham số có thể được sử dụng để thông báo cho khách hàng về các khả năng của máy chủ tài nguyên, ví dụ: cấu hình mà máy chủ tài nguyên hỗ trợ.

Yêu cầu tài nguyên (C):

Máy của người dùng tương tác với máy chủ tài nguyên để yêu cầu quyền truy cập vào tài nguyên được bảo vệ và cung cấp mã thông báo truy cập. Giao thức sử dụng giữa các bên không bị giới hạn đối với CoAP. HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, v.v., cũng là những giao thức ứng cử viên khả thi. Tùy thuộc vào các giới hạn của thiết bị và giao thức đã chọn, việc trao đổi này có thể được chia thành hai phần:

(1) Máy của người dùng gửi mã thông báo truy cập chứa hoặc tham chiếu thông tin ủy quyền tới RS sẽ được sử dụng cho các yêu cầu tài nguyên tiếp theo của máy của người dùng.

(2) Máy của người dùng thực hiện yêu cầu truy cập tài nguyên bằng cách sử dụng giao thức bảo mật truyền thông và thông tin truy cập khác thu được từ máy chủ ủy quyền.

Yêu cầu mã thông báo “Introspection” (D):

Một máy chủ tài nguyên có thể được định cấu hình để xem xét nội tại mã thông báo truy cập bằng cách đưa nó vào một yêu cầu tới điểm cuối nội quan tại máy chủ ủy quyền đó. Lưu ý rằng xem xét nội dung mã thông báo là một bước tùy chọn và có thể được bỏ qua nếu mã thông báo là độc lập và máy chủ tài nguyên được chuẩn bị để tự thực hiện xác thực mã thông báo.

Phản hồi mã thông báo “Introspection” (E):

Máy chủ ủy quyền xác thực mã thông báo và trả về các tham số gần đây nhất, chẳng hạn như scope, audience tính hợp lệ, v.v., được liên kết với nó trở lại máy chủ tài nguyên. Sau đó máy chủ tài nguyên sử dụng các tham số nhận được để xử lý yêu cầu chấp nhận hoặc từ chối nó.

Tài nguyên được Bảo vệ (F):

Nếu yêu cầu từ máy khách được ủy quyền, máy chủ tài nguyên sẽ thực hiện yêu cầu và trả về phản hồi với mã phản hồi thích hợp. Máy chủ tài nguyên sử dụng các khóa được thiết lập động để bảo vệ phản hồi theo giao thức bảo mật truyền thông được sử dụng.

Khung OAuth 2.0 xác định một số "luồng giao thức" thông qua các loại cấp, đã được mở rộng thêm với các phần mở rộng cho OAuth 2.0 (chẳng hạn như (RFC7521) và (RFC8628)). Loại tài trợ nào hoạt động tốt nhất phụ thuộc vào kịch bản sử dụng; (RFC7744) mô tả nhiều trường hợp sử dụng IoT khác nhau, nhưng có hai loại cấp bao gồm phần lớn các trường hợp này, đó là cấp mã ủy quyền và cấp thông tin xác thực của máy của người dùng. Việc cấp mã ủy quyền rất phù hợp để sử dụng với các ứng dụng chạy trên điện thoại thông minh và máy tính bảng yêu cầu quyền truy cập vào các thiết bị IoT, một tình huống phổ biến trong môi trường nhà thông minh, nơi người dùng cần trải qua giai đoạn xác thực và ủy quyền (ít nhất là trong giai đoạn đầu giai đoạn thiết lập). Nguyên tắc ứng dụng gốc được mô tả trong có thể áp dụng cho trường hợp sử dụng này. Việc cấp thông tin xác thực cho ứng dụng khách rất phù hợp để sử dụng với các thiết bị IoT mà bản thân ứng dụng khách OAuth bị hạn chế. Trong trường hợp như vậy, chủ sở hữu tài nguyên đã sắp xếp trước quyền truy cập cho máy của người dùng với máy chủ ủy quyền, điều này thường được thực hiện bằng cách sử dụng công cụ chạy thử.

Sự đồng ý của chủ sở hữu tài nguyên, để cấp cho khách hàng quyền truy cập vào tài nguyên được bảo vệ, có thể được cung cấp động như trong các luồng OAuth cổ điển hoặc nó có thể được chủ sở hữu tài nguyên định cấu hình trước dưới dạng các chính sách ủy quyền tại máy chủ ủy quyền, mà máy chủ ủy quyền sẽ đánh giá khi yêu cầu mã thông báo đến. Chủ sở hữu tài nguyên không được hiển thị trong Hình 1.

Khung này hỗ trợ nhiều cơ chế bảo mật truyền thông giữa các thực thể ACE, chẳng hạn như máy của người dùng, máy chủ ủy quyền và máy chủ tài nguyên. Giả định rằng máy của người dùng đã được đăng ký (còn được gọi là đăng ký hoặc giới thiệu) với một máy chủ ủy quyền bằng cách sử dụng một cơ chế được xác định bên ngoài phạm vi của tài liệu này. Trong thực tế, nhiều kỹ thuật khác nhau để giới thiệu đã được sử dụng, chẳng hạn như cung cấp tại nhà máy hoặc sử dụng các công cụ vận hành. Bất kể kỹ thuật giới thiệu là gì, thủ tục cung cấp này ngụ ý rằng máy của người dùng và máy chủ ủy quyền trao đổi thông tin xác thực và thông số cấu hình. Các thông tin xác thực này được sử dụng để xác thực lẫn nhau và để bảo vệ các thông điệp được trao đổi giữa máy của người dùng và máy chủ ủy quyền.

Kết luận

Trong bài viết này, Tiêu chuẩn Xác thực và ủy quyền cho môi trường bị ràng buộc (ACE) bằng cách sử dụng Khung OAuth 2.0 (ACE-OAuth) được giới thiệu đến bạn đọc một cách cơ bản . Đây là một tiêu chuẩn mới, việc triển khai mới ở bước đầu, tuy nhiên tầm nhìn thực tiễn của tiêu chuẩn là phù hợp với nhu cầu triển khai IoT trên toàn cầu.

Thông qua việc giới thiệu giao thức này, bài đọc đưa ra các cơ sở tri thức để người đọc hình dung và có cái nhìn cơ bản về triển khai ACE-OAuth 2.0. Việc thiết lập tiêu chuẩn này cũng sẽ nâng cao vấn đề an toàn thông tin cho mạng IoT.

Lê Nhật

Tài liệu tham khảo

1. L. Seitz (Combitech), G. Selander (Ericsson), E. Wahlstroem, S. Erdtman (Spotify AB), H. Tschofenig (Arm Ltd), Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth), RFC 9200, August 2022, ISSN: 2070-1721.