Các lựa chọn thay thế ký thông báo JSON


Huỳnh Tuyết Nga
3 năm trước
Hữu ích 6 Chia sẻ Viết bình luận 0
Đã xem 5208

Trong bài đăng này, chúng tôi khám phá các lựa chọn thay thế có sẵn để ký một thông báo JSON và sau đó xây dựng một so sánh giữa mỗi trong số chúng:

  • Chữ ký web JSON (JWS)
  • Chữ ký Cleartext JSON (JCS)
  • Ký hiệu đối tượng nhị phân (CBOR)

Chúng tôi đã thảo luận chi tiết về Chữ ký web JSON (JWS), trong bài trung bìnhJWT, JWS và JWE cho Not So Dummies! . JWS là một tiêu chuẩn IETF (RFC 7516), định nghĩa cách ký bất kỳ tải trọng nào (không nhất thiết là JSON, nó có thể là XML) và biểu thị tải trọng đã ký cùng với chữ ký và siêu dữ liệu được liên kết theo một trong hai định dạng được tuần tự hóa: JSON tuần tự hóa hoặc tuần tự hóa nhỏ gọn . JWS không lo lắng về việc chuẩn hóa - thực tế, nó không phải như vậy. Ở dạng tuần tự hóa, tải trọng ban đầu được bao gồm như vậy (được mã hóa chính xác base64url).

Chúng ta hãy nhanh chóng xem xét cả hai định dạng nối tiếp JWS:

 
           
       Cấu trúc của mã thông báo JWS được hình thành bởi tuần tự hóa nhỏ gọn JWS.      
     
 
           
       Cấu trúc của mã thông báo JWS được hình thành bằng cách tuần tự hóa JSON.      
     
 

Có nhiều thư viện hỗ trợ JWS:

JCS là một lược đồ để ký dữ liệu được thể hiện dưới dạng các đối tượng JSON (RFC 7159). Nó được mô hình hóa một cách lỏng lẻo sau các chữ ký XML En Enopedoped . So với đối tác XML của nó, JCS khá nguyên thủy, nhưng mặt khác, nó đã được chứng minh là đơn giản để thực hiện và sử dụng.

Đặc tả Chữ ký XML, được phát triển theo W3C đã giới thiệu 3 loại chữ ký: Bao bọc, Bao bọc và Tách rời.

Theo chữ ký Bao bọc, chữ ký của tải trọng đã ký (xml) được nhúng vào chính tải trọng đó. Nói cách khác, phần tử <Chữ ký>, giữ chữ ký thực và siêu dữ liệu liên quan trở thành một phần tử con của tải trọng xml sẽ được ký.

Theo chữ ký Enveloping, chữ ký của tải trọng đã ký (xml) nhúng tải trọng vào chính nó. Nói cách khác, phần tử <Chữ ký>, giữ chữ ký thực và siêu dữ liệu liên quan trở thành phần tử chính của tải trọng xml sẽ được ký.

Theo chữ ký tách ra, chữ ký của tải trọng đã ký (xml) được tách ra khỏi chính tải trọng đó. Nói cách khác, phần tử <Chữ ký>, giữ chữ ký thực và siêu dữ liệu liên quan không phải là phần tử cha cũng không phải là phần tử con của tải trọng xml được ký.

Vào cuối năm 2013, JCS được phát triển bởi Anders Rundgren như một phần của dự án OpenKeyStore , nơi chữ ký được mã hóa giống như chữ ký XML được bao bọc, chỉ có trong JSON. Không giống như JWS (JOSE) của IETF, JCS được thiết kế để trở thành một phần không thể thiếu của một đối tượng JSON thay vì nhúng dữ liệu đã ký.

 
           
       Ví dụ về một thông báo JSON được ký với JCS.     
     
 

Theo JCS, thông báo JSON phải được chuẩn hóa trước, trước khi ký. Các quy tắc chuẩn hóa được xác định tại đây: https://cyberphone.github.io/openkeystore/resource/docs/jcs.html .

Phải xóa khoảng trắng mà theo nghĩa thực tế có nghĩa là loại bỏ tất cả các ký tự bên ngoài các chuỗi được trích dẫn có giá trị x09, x0a, x0d hoặc x20.

Các chuỗi thoát JSON '\ /' phải được vinh danh trên đầu vào trong các chuỗi được trích dẫn nhưng được coi là một chuỗi tương đương với bộ suy biến thành '/' bằng cách viết lại chúng.

Trình tự thoát Unicode ('\ uhhhh') trong các chuỗi được trích dẫn phải được điều chỉnh như sau: Nếu giá trị Unicode nằm trong phạm vi ký tự điều khiển ASCII truyền thống (0x00 đùa0x1f), thì phảiđược viết lại bằng ký hiệu thập lục phân chữ thường, trừ khi đó là một trong các thoát JSON được xác định trước ('\ n', v.v.) vì cái sau có trước. Nếu giá trị Unicode nằm ngoài phạm vi ký tự điều khiển ASCII, thì nó phải được thay thế bằng ký tự Unicode tương ứng ngoại trừ '' 'và' \ 'luôn luôn phải được thoát. Bây giờ

đối tượng JSON được liên kết với chữ ký phải được tạo lại bằng văn bản thực tế còn lại sau khi áp dụng các biện pháp trước đó. Cơ sở lý luận: Các số JSON được định nghĩa một cách mơ hồ (Tiếng không bình thường hóa), có nghĩa là một chuỗi giải mã / mã hóa có thể tạo ra một biểu diễn khác so với ban đầu. Ví dụ, dữ liệu dấu phẩy động thường được biểu thị như 4.50 mặc dù số 0 ở cuối là không dư thừa. Để đối phó với vấn đề tiềm ẩn này, các trình phân tích cú pháp tuân thủ phải   bảo toàn biểu diễn văn bản gốc của các thuộc tính bên trong để hỗ trợ các yêu cầu chuẩn hóa JCS.

JCS không có nhiều triển khai hỗ trợ. Việc triển khai tham chiếu JCS có sẵn tại https://github.com/cyberphone/openkeystore .

Biểu diễn đối tượng nhị phân ngắn gọn (CBOR) là định dạng dữ liệu với mục tiêu thiết kế bao gồm khả năng kích thước mã cực nhỏ, kích thước thông báo khá nhỏ và khả năng mở rộng mà không cần đàm phán phiên bản. Mô hình dữ liệu cơ bản của CBOR là phiên bản mở rộng của mô hình dữ liệu JSON, như được định nghĩa trong RFC 7049. Văn bản JSON là một chuỗi ký tự, không phải là chuỗi byte được mã hóa, trong khi mục dữ liệu CBOR bao gồm byte, không phải ký tự. RFC 7049 cũng xác định việc chuyển đổi từ JSON sang CBOR và ngược lại.

Một số ứng dụng muốn sử dụng JSON cần vận chuyển dữ liệu nhị phân, chẳng hạn như chữ ký, khóa mã hóa, dữ liệu đồ họa hoặc giá trị cảm biến. Trong JSON, những dữ liệu này cần được mã hóa (thường ở định dạng base64), thêm độ phức tạp và số lượng lớn. Nếu bạn có thể nhớ lại, trong JWS, nó sử dụng mã hóa base64url.

Đặc tả dự thảo - Cú pháp tin nhắn được mã hóa CBOR , được tạo ra trong nhóm làm việc IETF COSE (Mã hóa và ký hiệu đối tượng CBOR), chỉ định xử lý chữ ký, mã xác thực tin nhắn và mã hóa bằng CBOR. Nó cũng chỉ định một đại diện cho các khóa mật mã bằng cách sử dụng CBOR.

Nhóm làm việc IETF JOSE đã tạo ra một bộ tài liệu cho JWT, JWS, JWE, JWA bằng JSON chỉ định cách xử lý mã hóa, chữ ký và xác thực thông báo (MAC) và cách mã hóa khóa bằng JSON. Nhóm làm việc IETF COSE thực hiện công việc tương tự để sử dụng với định dạng tài liệu CBOR (RFC 7049).

 
           
       Tin nhắn đã ký được sản xuất theo ký hiệu đối tượng CBOR với một chữ ký.      
     
 

COSE hỗ trợ hai cấu trúc chữ ký khác nhau. COSE_Sign cho phép một hoặc nhiều người ký được áp dụng cho một nội dung duy nhất (như tuần tự hóa JWS JSON). COSE_Sign1 bị giới hạn ở một người ký duy nhất (như tuần tự hóa nhỏ gọn JWS).

Cấu trúc COSE_Sign là một mảng CBOR. Một trong những yếu tố trong mảng là tải trọng . Các tải trọng chứa các nội dung theo bộ sẽ được ký kết. Nếu tải trọng không có trong thông báo, ứng dụng được yêu cầu cung cấp tải trọng riêng. Các tải trọng được bọc trong một BSTR (một chuỗi byte)  để đảm bảo rằng nó được vận chuyển mà không cần thay đổi. Nếu tải trọng được vận chuyển riêng (tức là nội dung tách rời), thì một đối tượng CBOR không được đặt ở vị trí này và trách nhiệm của ứng dụng là đảm bảo rằng nó sẽ được vận chuyển mà không thay đổi.

Tên được xác định trước cho các loại, ví dụ bstr được xác định trong ngôn ngữ định nghĩa dữ liệu CBOR (CDDL): https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-07

Mặc dù các thư viện hỗ trợ Ký đối tượng CBOR vẫn chưa đến, nhưng có nhiều thư viện hỗ trợ chính CBOR:

JWS do nhóm làm việc IETF JOSE sản xuất là tiêu chuẩn duy nhất hiện có dưới dạng RFC, định nghĩa cách biểu thị một tải trọng đã ký (JSON hoặc bất cứ thứ gì) theo các định dạng được tuần tự hóa được hỗ trợ của nó: tuần tự hóa nhỏ gọn hoặc tuần tự hóa JSON. JWS được chấp nhận rộng rãi và có nhiều hỗ trợ thư viện dưới nhiều nền tảng.

Công việc đang được tiến hành trong nhóm làm việc của IETF COSE là tạo ra một bộ RFC để làm cho công việc của nhóm làm việc IETF JOSE được áp dụng nhiều hơn trong một môi trường bị hạn chế. CBOR đang được chấp nhận bởi một số nhóm làm việc của IETF liên quan đến thế giới IoT dưới dạng mã hóa cấu trúc dữ liệu của họ. CBOR được thiết kế đặc biệt vừa nhỏ về mặt truyền tải thông tin và kích thước triển khai cũng như có bộ giải mã không có lược đồ. Khi có nhu cầu cung cấp dịch vụ bảo mật tin nhắn cho IoT và sử dụng CBOR làm định dạng mã hóa tin nhắn, thì CBOR Object Signing có ý nghĩa hơn là chỉ sử dụng JWS đơn giản. CBOR Object Signing tương đối mới và chưa tìm thấy bất kỳ thư viện nào hỗ trợ điều đó.

JCS không phải là một tiêu chuẩn được chấp nhận rộng rãi hoặc không có cơ quan tiêu chuẩn được chấp nhận rộng rãi đằng sau nó. Trọng tâm của nó là làm cho chữ ký trở thành một phần không thể thiếu của tải trọng đã ký. Chỉ có một thư viện chúng tôi tìm thấy, hỗ trợ triển khai JCS. Mọi thứ bạn có thể làm với JCS đều có thể được thực hiện với JWS - do đó, trong hầu hết các trường hợp, JWS là tùy chọn ưa thích hơn JCS. Ngoài ra, cả Ký kết đối tượng JWS và CBOR không chỉ là về việc ký một tải trọng JSON - mà là bất cứ điều gì, trong khi JCS chỉ là về việc ký một tải trọng JSON.

 


Hữu ích 6 Chia sẻ Viết bình luận 0
Đã xem 5208