Chữ ký web JSON - JSON Web Signature (JWS) 

Chữ ký Web JSON (JWS) đại diện cho nội dung được bảo mật bằng chữ ký số hoặc Mã xác thực tin nhắn (MAC) bằng cách sử dụng cấu trúc dữ liệu dựa trên JSON. Các thuật toán và số nhận dạng mật mã để sử dụng với đặc điểm kỹ thuật này được mô tả trong thông số kỹ thuật Thuật toán web JSON Web Algorithms (JWA) một cách tách biệt và trong danh sách của tổ chức cấp phát số hiệu chuẩn Internet (IANA). Các khả năng mã hóa liên quan được mô tả trong thông số kỹ thuật Mã hóa web JSON Web Encryption (JWE). JWS cũng là thành phần cuối của mã thông báo web JSON Web Token (JWT) và có vai trò quan trọng nhất trong việc bảo mật của mã thông báo này.

Bài viết dựa trên tài liệu theo dõi tiêu chuẩn mở Internet. Đây là sản phẩm của nhóm chuyên viên kỹ thuật Internet (IETF) và hoành thành vào tháng 05 năm 2015. Những tác giả chính của tiêu chuẩn là M. Jones làm việc tại Microsoft, J. Bradley đến từ Ping indentity và N. Sakirumra đến từ NRI. Nó là sản phẩm thể hiện sự chung sức của cộng đồng IETF đồng thời nó đã nhận được đánh giá công khai và được phê duyệt đề xuất bản bởi khối chỉ đạo kỹ thuật Internet (IESG). Tài liệu này là thành phần đi kèm của tiêu chuẩn cho mã thông báo web JWT. Đây là tài liệu mở nhưng dễ hiểu và dễ sử dụng, tài liệu được sử dụng như một phần của của tài liệu chính JWT, mục đích của tài liệu là khẳng định yếu tố mã hóa. Đây là phiên bản duy nhất và vẫn được giữ được sự tin cậy cao trong các tiêu chuẩn mạng.

Nội dung chi tiết

1. Khái quát JWS

JWS hay JSON Web Signature là một dạng chữ kỹ có tác dụng xác minh chính trong JWT được viết với ngôn ngữ JavaScript Object Notaion (JSON) trên nền tảng web. Về mặt kỹ thuật JWS đại diện cho nội dung được ký số hoặc MACed bằng cách sử dụng cấu trúc dữ liệu JSON và mã hóa base64url. Các cấu trúc dữ liệu JSON này có thể chứa khoảng trắng hoặc ngắt dòng trước hoặc sau bất kỳ giá trị JSON hoặc ký tự cấu trúc nào, phù hợp với định dạng dữ liệu của JSON được viết chi tiết trong RFC 7159 [RFC7159]. JWS đại diện cho các giá trị logic này (mỗi giá trị được định nghĩa trong Phần 2):

- JOSE Header

- JWS Payload

- JWS          

Đối với mỗi một JWS, các thành phần JOSE Header là sự kết hợp của các giá trị này:

- JWS Protected Header: Giá trị này khi JWS sử dụng tuần tự hóa JWS Compact.

- JWS Unprotected Header: Giá trị này khi JWS sử dụng tuần tự hóa JWS JSON có chứa các tham số của tiêu đề không được toàn vẹn.

Hình 1: Giá trị của JWS trong JWT

2. Tiến trình tuần tự JWS

JWS sử dụng một trong hai cách tuần tự hóa: Tuần tự hóa JWS Compact hoặc Chuỗi tuần tự JWS JSON. Các ứng dụng cụ thể sử dụng thông số kỹ thuật này cần chỉ định các tính năng tuần tự hóa và tuần tự hóa nào được sử dụng cho ứng dụng đó. Ví dụ: các ứng dụng có thể chỉ định rằng chỉ sử dụng tuần tự hóa JWS JSON, chỉ sử dụng JWS JSON cho một chữ ký hoặc giá trị MAC; hoặc cũng có thể sử dụng hỗ trợ cho nhiều chữ ký hoặc giá trị MAC. Việc triển khai JWS chỉ cần triển khai các tính năng cần thiết cho các ứng dụng mà chúng được thiết kế để hỗ trợ.

Đối với tuần tự hóa JWS Compact, nó đại diện cho nội dung được ký kỹ thuật số hoặc MACed dưới dạng một chuỗi nhỏ gọn, an toàn cho URL. Chuỗi này là:

BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)
Chỉ một chữ ký hoặc điện chỉ MAC được hỗ trợ bởi JWS Compact và nó không cung cấp cú pháp nào để đại diện cho giá trị JWS Unprotected Header.
Đối với tuần tự hóa JWS JSON, nó đại diện cho nội dung được ký số hoặc MACed dưới dạng đối tượng JSON. Biểu diễn này không được tối ưu hóa cho sự gọn nhẹ cũng như không an toàn cho URL. Chuỗi này sẽ là:
{
      "payload":"<payload contents>",
      "signatures":[
       {"protected":"<integrity-protected header 1 contents>",
        "header":<non-integrity-protected header 1 contents>,
        "signature":"<signature 1 contents>"},
       ...
       {"protected":"<integrity-protected header N contents>",
        "header":<non-integrity-protected header N contents>,
        "signature":"<signature N contents>"}]
}

Hình 2: Ví dụ về chữ ký web JSON không có mã hóa bí mật base64

Hình 3: Ví dụ về chữ ký web JSON có mã hóa bí mật base64

3. Tiêu đề JOSE

Đối với JWS, các thành phần của (các) đối tượng JSON đại diện cho tiêu đề JOSE mô tả chữ ký số hoặc MAC được áp dụng cho JWS Protected Header và JWS Payload và các thuộc tính bổ sung tùy chọn của JWS. Tên tham số tiêu đề trong JOSE PHẢI là duy nhất; Bộ phân tích cú pháp JWS PHẢI từ chối các JWS có tên tiêu đề trùng lặp hoặc sử dụng bộ phân tích cú pháp JSON chỉ trả về tên thành viên trùng lặp về mặt từ vựng, như được chỉ định trong ECMAScript 5.1 [ECMAScript].

Có ba lớp tên Tham số tiêu đề: Tên tham số tiêu đề đã đăng ký, tên tham số tiêu đề công khai và tên tham số tiêu đề riêng.

Tên tham số tiêu đề đã đăng ký bao gồm các giá trị dưới đây:

Tiêu đề

Ý nghĩa

“alg” (algorithm)

Xác định thuật toán mật mã được sử dụng để bảo mật JWS. Giá trị Chữ ký JWS không hợp lệ nếu giá trị "alg" không đại diện cho thuật toán được hỗ trợ hoặc nếu không có khóa để sử dụng với thuật toán đó được liên kết với bên đã ký kỹ thuật số hoặc MACed nội dung. các giá trị "alg" phải được đăng ký trong sổ đăng ký "Thuật toán mã hóa và chữ ký web JSON" của IANA do [JWA] thiết lập hoặc là giá trị chứa Tên chống va chạm. Giá trị "alg" là một chuỗi ASCII phân biệt chữ hoa chữ thường có chứa giá trị StringOrURI. Thông số Header này phải có mặt và phải được hiểu và xử lý bởi các triển khai.

“jku”

(JWK Set URL)

Là một URI [RFC3986] đề cập đến một tài nguyên cho một tập hợp các khóa công khai được mã hóa JSON, một trong số đó tương ứng với khóa được sử dụng để ký kỹ thuật số JWS. Các khóa phải được mã hóa dưới dạng bộ JWK [JWK]. Giao thức được sử dụng để lấy tài nguyên phải cung cấp khả năng bảo vệ toàn vẹn; một yêu cầu HTTP GET để truy xuất bộ JWK phải sử dụng bảo mật lớp truyền tải (TLS) [RFC2818] [RFC5246]; và danh tính của máy chủ phải được xác thực. Việc sử dụng tham số tiêu đề này là tùy chọn.

“jwk”

(JSON Web Key)

Là khóa công khai tương ứng với khóa dùng để ký điện tử JWS. Khóa này được biểu diễn dưới dạng Khóa web JSON [JWK]. Việc sử dụng tham số tiêu đề này là tùy chọn.

“kid” (Key ID)

Là một gợi ý cho biết khóa nào đã được sử dụng để bảo mật JWS. Tham số này cho phép người khởi tạo báo hiệu rõ ràng về sự thay đổi khóa cho người nhận. Cấu trúc của giá trị "kid" là không xác định. Giá trị của nó phải là một chuỗi phân biệt chữ hoa chữ thường. Việc sử dụng tham số tiêu đề này là tùy chọn.

Khi được sử dụng với JWK, giá trị "kid" được sử dụng để khớp với giá trị tham số JWK "kid".

“x5u”

(X.509 URL)

Là URI [RFC3986] đề cập đến tài nguyên cho chứng chỉ khóa công khai X.509 hoặc chuỗi chứng chỉ [RFC5280] tương ứng với khóa được sử dụng để ký kỹ thuật số JWS. Tài nguyên được xác định phải cung cấp bản đại diện của chứng chỉ hoặc chuỗi chứng chỉ phù hợp với RFC 5280 [RFC5280] ở dạng được mã hóa PEM. Chứng chỉ có chứa phải là chứng chỉ đầu tiên. Điều này CÓ THỂ được theo sau bởi các chứng chỉ bổ sung, với mỗi chứng chỉ tiếp theo là chứng chỉ được sử dụng để chứng nhận chứng chỉ trước đó. Giao thức được sử dụng để lấy tài nguyên phải cung cấp khả năng bảo vệ toàn vẹn; một yêu cầu HTTP GET để truy xuất chứng chỉ PHẢI sử dụng TLS [RFC2818] [RFC5246]; và danh tính của máy chủ PHẢI được xác thực. Việc sử dụng tham số tiêu đề này là tùy chọn.

“x5c”

(X.509 Certificate Chain)

Là tiêu đề chứa chứng chỉ khóa công khai X.509 hoặc chuỗi chứng chỉ [RFC5280] tương ứng với khóa được sử dụng để ký kỹ thuật số JWS. Chứng chỉ hoặc chuỗi chứng chỉ được biểu diễn dưới dạng một mảng JSON của các chuỗi giá trị chứng chỉ. Mỗi chuỗi trong mảng là một giá trị chứng chỉ PKIX được mã hóa base64 (Phần 4 của [RFC4648] - không được mã hóa base64url) DER [ITU.X690.2008]. Chứng chỉ có chứa khóa công khai tương ứng với khóa được sử dụng để ký điện tử JWS phải là chứng chỉ đầu tiên. Điều này có thể được theo sau bởi các chứng chỉ bổ sung, với mỗi chứng chỉ tiếp theo là chứng chỉ được sử dụng để chứng nhận chứng chỉ trước đó. Người nhận phải xác thực chuỗi chứng chỉ theo RFC 5280 [RFC5280] và coi chứng chỉ hoặc chuỗi chứng chỉ là không hợp lệ nếu xảy ra bất kỳ lỗi xác thực nào. Việc sử dụng tham số tiêu đề này là tùy chọn.

“x5t”

(X.509 Certificate SHA-1 Thumbprint)

Là bản sao SHA-1 được mã hóa base64url (còn gọi là thông báo) của mã hóa DER của chứng chỉ X.509 [RFC5280] tương ứng với khóa được sử dụng để ký số JWS. Việc sử dụng tham số tiêu đề này là tùy chọn.

"x5t#S256" (X.509 Certificate SHA-256 Thumbprint)

Là một dấu nhỏ SHA-256 được mã hóa base64url (còn gọi là thông báo) của mã hóa DER của chứng chỉ X.509 [RFC5280] tương ứng với khóa được sử dụng ký điện tử JWS. Việc sử dụng tham số tiêu đề này là tùy chọn.

"typ" (Type) Header Parameter

Được các ứng dụng JWS sử dụng để khai báo loại phương tiện [IANA.MediaTypes] của JWS hoàn chỉnh này. Điều này được thiết kế để ứng dụng sử dụng khi có thể có nhiều hơn một loại đối tượng trong cấu trúc dữ liệu ứng dụng có thể chứa JWS; ứng dụng có thể sử dụng giá trị này để phân biệt giữa các loại đối tượng khác nhau có thể có mặt. Nó thường sẽ không được các ứng dụng sử dụng khi loại đối tượng đã được biết trước. Tham số này bị bỏ qua bởi các triển khai JWS; bất kỳ quá trình xử lý tham số này được thực hiện bởi ứng dụng JWS. Việc sử dụng tham số tiêu đề này là tùy chọn.

Theo RFC 2045 [RFC2045], tất cả các giá trị kiểu phương tiện, giá trị kiểu con và tên tham số không phân biệt chữ hoa chữ thường. Tuy nhiên, các giá trị tham số phân biệt chữ hoa chữ thường trừ khi được chỉ định khác cho tham số cụ thể.

 Để giữ cho thông điệp gọn gàng trong các tình huống phổ biến, nhà sản xuất nên bỏ qua tiền tố "ứng dụng /" của giá trị loại phương tiện trong Tham số tiêu đề "typ" khi không có '/' nào khác xuất hiện trong giá trị loại phương tiện. Người nhận sử dụng giá trị loại phương tiện PHẢI coi nó như thể "application /" đã được thêm vào trước bất kỳ giá trị "typ" nào không chứa '/'. Ví dụ: giá trị "typ" của "example" NÊN được sử dụng để đại diện cho loại phương tiện "ứng dụng / ví dụ", trong khi loại phương tiện "application / example; part =" 1/2 "" không thể được rút ngắn thành "example; phần = "1/2" ".

Giá trị "typ" là "JOSE" có thể được sử dụng bởi các ứng dụng để chỉ ra rằng đối tượng này là JWS hoặc JWE bằng cách sử dụng JWS Compact Serialization hoặc JWE Compact Serialization. Giá trị "typ" "JOSE + JSON" có thể được ứng dụng sử dụng để chỉ ra rằng đối tượng này là JWS hoặc JWE bằng cách sử dụng JWS JSON Serialization hoặc JWE JSON Serialization. Các ứng dụng cũng có thể sử dụng các giá trị kiểu khác.

"cty"

(Content Type)

Được các ứng dụng JWS sử dụng để khai báo loại phương tiện [IANA.MediaTypes] của nội dung được bảo mật (tải trọng). Điều này được thiết kế để ứng dụng sử dụng khi có thể có nhiều hơn một loại đối tượng trong JWS Payload; ứng dụng có thể sử dụng giá trị này để phân biệt giữa các loại đối tượng khác nhau có thể có mặt. Nó thường sẽ không được các ứng dụng sử dụng khi loại đối tượng đã được biết trước. Tham số này bị bỏ qua bởi các triển khai JWS; bất kỳ quá trình xử lý tham số này được thực hiện bởi ứng dụng JWS. Việc sử dụng tham số h này là tùy chọn.

Theo RFC 2045 [RFC2045], tất cả các giá trị kiểu phương tiện, giá trị kiểu con và tên tham số không phân biệt chữ hoa chữ thường. Tuy nhiên, các giá trị tham số phân biệt chữ hoa chữ thường trừ khi được chỉ định khác cho tham số cụ thể.

Để giữ cho thông điệp gọn gàng trong các tình huống phổ biến, khuyến cáo rằng nhà sản xuất bỏ qua tiền tố "application /" của giá trị loại phương tiện trong Thông số tiêu đề "cty" khi không có '/' nào khác xuất hiện trong giá trị loại phương tiện. Người nhận sử dụng giá trị loại phương tiện PHẢI coi nó như thể "application /" được thêm vào trước bất kỳ giá trị "cty" nào không chứa '/'. Ví dụ: giá trị "cty" của "example" NÊN được sử dụng để đại diện cho loại phương tiện "ứng dụng / ví dụ", trong khi loại phương tiện "application / example; part =" 1/2 "" không thể được rút ngắn thành "example; phần = "1/2" ".

"crit" (Critical) Header Parameter

 

Thông số tiêu đề "crit" (quan trọng) chỉ ra rằng các phần mở rộng cho đặc điểm kỹ thuật này và / hoặc [JWA] đang được sử dụng phải được hiểu và xử lý. Giá trị của nó là một mảng liệt kê các tên thông số tiêu đề có trong Tiêu đề JOSE sử dụng các phần mở rộng đó. Nếu bất kỳ tham số tiêu đề tiện ích mở rộng nào được liệt kê không được người nhận hiểu và hỗ trợ, thì JWS không hợp lệ. Nhà sản xuất không được bao gồm tên tham số tiêu đề được xác định bởi thông số kỹ thuật này hoặc [JWA] để sử dụng với JWS, tên trùng lặp hoặc tên không xuất hiện dưới dạng tên tham số tiêu đề trong tiêu đề JOSE trong danh sách "crit".

Nhà sản xuất không được sử dụng danh sách trống "[]" làm giá trị "crit". Người nhận có thể coi JWS là không hợp lệ nếu danh sách quan trọng chứa bất kỳ tên Thông số tiêu đề nào được xác định bởi đặc tả này hoặc [JWA] để sử dụng với JWS hoặc nếu bất kỳ ràng buộc nào khác về việc sử dụng nó bị vi phạm. Khi được sử dụng, Thông số Header này phải được bảo vệ toàn vẹn; do đó, nó phải xảy ra chỉ trong JWS Protected Header. Việc sử dụng tham số tiêu đề này là tùy chọn. Tham số tiêu đề này phải được hiểu và xử lý bởi các triển khai.

Một ví dụ sử dụng, cùng với trường "exp" (thời gian hết hạn) giả định là:

{

      "alg": "ES256",

      "crit": ["exp"],

      "exp": 1363284000

}

Tên tham số tiêu đề công khai:

Tên tham số tiêu đề bổ sung có thể được xác định bởi những người sử dụng JWS. Tuy nhiên, để tránh va chạm, bất kỳ tên Tham số tiêu đề mới nào cũng phải được đăng ký trong sổ đăng ký IANA "Các tham số tiêu đề mã hóa và chữ ký web JSON" được thiết lập bởi Tên công khai (một giá trị chứa Tên chống va chạm). Trong mỗi trường hợp, người định nghĩa tên hoặc giá trị cần phải thực hiện các biện pháp phòng ngừa hợp lý để đảm bảo rằng họ đang kiểm soát phần của không gian tên mà họ sử dụng để xác định tên Tham số tiêu đề.

Các tham số tiêu đề mới nên được giới thiệu một cách hạn chế, vì chúng có thể dẫn đến các JWS không thể tương tác.

Tên tham số tiêu đề riêng:

Nhà sản xuất và người tiêu dùng JWS có thể đồng ý sử dụng tên Tham số tiêu đề là tên riêng (tên không phải là tên tham số tiêu đề đã đăng ký) hoặc tên tham số tiêu đề công khai. Không giống như tên tham số tiêu đề công khai, tên tham số tiêu đề riêng có thể bị va chạm và nên được sử dụng một cách thận trọng.

4. Khía cạnh bảo mật

Tất cả các vấn đề bảo mật liên quan đến bất kỳ ứng dụng mật mã nào đều phải được giải quyết bởi các loại mã JWS / JWE / JWK. Trong số các vấn đề này là bảo vệ các khóa bí mật đối xứng và riêng tư bất đối xứng của người dùng và sử dụng các biện pháp đối phó với các cuộc tấn công khác nhau.

Tất cả các cân nhắc bảo mật trong "Cú pháp và xử lý chữ ký XML Phiên bản 2.0" [W3C.NOTE-xmldsig-core2-20130411], cũng áp dụng cho đặc tả này, ngoài những đặc tả dành riêng cho XML. Tương tự như vậy, nhiều phương pháp hay nhất được ghi lại trong "Các phương pháp hay nhất về chữ ký XML" [W3C.NOTE-xmldsig-bestpractices-20130411] cũng áp dụng cho đặc tả này, ngoại trừ những phương pháp dành riêng cho XML.

Kết luận

Có thể thấy JSON Web Signature (JWS) hay chữ ký web JSON khá là phức tạp về mặt lập trình và yêu cầu sự hiểu biết nhất định về code. Tuy nhiên việc nắm bắt được JWS là yếu tố cố lõi của mã thông báo JWT, là yếu tố quan trọng trong việc tổng hợp mã thông báo và mã hóa một cách bất kì. Điều này tránh được sự tấn công của kẻ gian nhờ việc linh hoạt mã hóa. Việc hiểu được cái giá trị cốt lỗi của JWS hay các tiêu đề JSON sẽ giúp việc xây dựng JWT chính xác và hiệu quả.

Thông qua tiêu chuẩn mở này, ta có thêm các khía cạnh về bảo mật để xây dựng các nền tảng mới, đặc biệt nó là thành phần quan trọng trong mã thông báo JWT hay trong tiêu chuẩn OpenID Connect 1.0.

Vũ Cao Minh Đức

Tài liệu tham khảo

1. XML Signature Syntax and Processing Version 2.0

2. JSON Web Signature (https://tools.ietf.org/html/rfc7515)

1584 Go top

Ý kiến về Trang thông tin điện tử Cục Tin học hóa?
1. Đạt yêu cầu, 1180 phiếu (88 %)
2. Chưa đạt yêu cầu, 107 phiếu (8 %)
3. Cần thêm chủ đề, 57 phiếu (4 %)
Tổng số phiếu: 1344
THÔNG KÊ TRUY CẬP
  • Người trực tuyến Người trực tuyến
    • Khách Khách 60
    • Thành viên Thành viên 0
    • Tổng Tổng 60
    • Tổng lượt truy cập: Tổng lượt truy cập: 17155629