Công cụ dành cho nhà phát triển · Bộ giải mã JWT
JWE Giải thích: Tại sao JWT được mã hóa có năm phần và không có tải trọng có thể đọc được
· Lý lịch
jwt mã hóa data-formats
Một số mã thông báo có bốn dấu chấm thay vì hai dấu chấm và trọng tải không phải là JSON. Bài đăng này giải thích về chuỗi tuần tự nhỏ gọn JWE, ý nghĩa của từng phần trong số năm phần của nó và lý do tại sao không có công cụ chỉ giải mã nào có thể hiển thị các xác nhận của nó.
Bốn dấu chấm và trọng tải không phải là JSON — biển báo bạn đang cầm JWE chứ không phải JWS
Bốn dấu chấm và năm đoạn biểu thị một phong bì nhỏ gọn khác với biểu mẫu có chữ ký ba phần quen thuộc. Việc cố gắng phân tích cú pháp các byte giữa của nó dưới dạng tuyên bố JWT sẽ tạo ra điều vô nghĩa vì nội dung là văn bản mã hóa chứ không phải cách viết base64url của văn bản gốc JSON.
ToolAcre kiểm tra số lượng phân đoạn trước khi giải mã. Năm phần kích hoạt thông báo INVALID_JWT xác định JWE và giải thích lý do tại sao tuyến đường chỉ giải mã này không hiển thị mà không có khóa giải mã. Đó là một ranh giới chính xác chứ không phải là một lỗi phân tích mơ hồ.
Năm phần - tiêu đề được bảo vệ, khóa mã hóa, vectơ khởi tạo, văn bản mã hóa và thẻ xác thực
Các phần JWE nhỏ gọn thể hiện tiêu đề được bảo vệ, tài liệu khóa được mã hóa, giá trị khởi tạo, văn bản mã hóa và thẻ xác thực. Mỗi cái có một vai trò mật mã riêng biệt. Chỉ riêng vị trí phân đoạn không làm cho trường thứ hai hoặc thứ tư trở thành tải trọng JWT có thể đọc được.
Bộ giải mã có thể phân tách và giải mã base64url một số byte, nhưng byte thô không phải là giải mã. Hiển thị chúng dưới dạng văn bản sẽ tạo ra các ký tự thay thế hoặc các đoạn gây hiểu lầm. Hành động đúng là xác định phong bì và chuyển sang triển khai người nhận được ủy quyền.
alg và enc — quản lý khóa so với mã hóa nội dung và lý do tiêu đề JWE đặt tên cho hai thuật toán
Tiêu đề JWE có thể chứa `alg` để quản lý khóa và `enc` để mã hóa nội dung. Các nhãn này mô tả các hoạt động khác nhau. Giống như mã thông báo đã ký, giá trị tiêu đề là thông tin đầu vào phải phù hợp với chính sách của người nhận thay vì cho phép mã thông báo chọn thuật toán tùy ý.
Ghi chú thuật toán ba phần của ToolAcre không triển khai quá trình xử lý JWE và nhánh năm phần thoát ra trước khi phân tích cú pháp tiêu đề. Do đó, trang này không hiển thị hoặc xác nhận các thuật toán mã hóa cụ thể. Tham khảo thư viện người nhận và hợp đồng phát hành để biết các lựa chọn được hỗ trợ.
Khóa mã hóa nội dung - cách khóa ngẫu nhiên bảo vệ tải trọng và được gói cho người nhận
Mã hóa nội dung thường sử dụng khóa mã hóa nội dung được tạo ra, trong khi phân đoạn khóa được mã hóa truyền hoặc lấy khóa đó theo sự sắp xếp của người nhận. Việc phân tách cho phép các byte tải trọng được bảo vệ bằng mật mã nội dung trong khi chính sách quản lý khóa xác định ai có thể khôi phục khóa.
Mô hình khái niệm này giải thích tại sao việc sở hữu chuỗi nhỏ gọn là không đủ để phục hồi bản rõ. Các bí mật và chính sách được yêu cầu của người nhận không được mã hóa dưới dạng hướng dẫn có thể sử dụng tự do. Bộ giải mã công khai không thể phát minh ra chúng và không bao giờ được yêu cầu người dùng dán khóa giải mã riêng tư vào một trang chung.
Khi tổ chức phát hành chọn JWE — các yêu cầu phải được giữ bí mật với khách hàng hoặc với các bên trung gian
Nhà phát hành có thể chọn mã hóa khi các yêu cầu phải được giữ bí mật với chủ sở hữu hoặc người trung gian có thể nhìn thấy mã thông báo đã ký. Liệu đó có phải là lựa chọn đúng đắn hay không còn phụ thuộc vào mô hình mối đe dọa, yêu cầu phân phối khóa và hoạt động. Việc giảm thiểu nội dung xác nhận quyền sở hữu vẫn có thể được ưu tiên hơn là mã hóa dữ liệu không cần thiết.
Mã hóa không loại bỏ các mối lo ngại về ủy quyền, xác thực hoặc siêu dữ liệu. Người nhận phải xác thực nội dung được bảo vệ và áp dụng chính sách mã thông báo sau khi giải mã. Kết quả có thể đọc được do người nhận được ủy quyền thu được không tự động được chấp nhận đối với mọi dịch vụ.
Tại sao quá trình giải mã dừng lại ở tiêu đề - tải trọng là văn bản mã hóa, vì vậy chỉ người giữ khóa mới có thể đọc được nó
Việc giải mã dừng lại ở cấu trúc vì phân đoạn tải trọng sẽ là văn bản mã hóa. ToolAcre cố tình tránh hiển thị nhị phân tùy ý dưới dạng JSON và thay vào đó đưa ra một thông báo cụ thể. Điều này giúp người dùng không hiểu những từ vô nghĩa là lỗi trong một phong bì được mã hóa hợp lệ.
Nếu bạn là người nhận dự kiến, hãy sử dụng phần mềm được kiểm soát được định cấu hình bằng khóa và thuật toán thích hợp. Nếu không, tải trọng không thể đọc được là thuộc tính bảo mật dự kiến. Không có thủ thuật đệm hoặc bộ giải mã ký tự thay thế nào có thể thay thế được việc giải mã.
Điều này không bao gồm những gì - JWT lồng nhau được ký và sau đó được mã hóa và JWE JSON tuần tự hóa
Các cấu trúc lồng nhau có thể ký nội dung và sau đó mã hóa kết quả hoặc kết hợp các lớp theo một cấu hình xác định. JWE cũng có các biểu diễn ngoài chuỗi năm phần nhỏ gọn. ToolAcre không xử lý những trường hợp đó và bài viết này không suy ra việc lồng ghép chỉ từ nhãn tiêu đề.
Ghi lại lớp mà hệ thống của bạn mong đợi trước khi khắc phục sự cố. Mặt khác, một nhóm có thể thử xác minh chữ ký trên văn bản mã hóa hoặc giải mã mã thông báo bên trong chưa được xác thực. Cho phép thư viện JOSE đã chọn xử lý việc đặt hàng theo chính sách rõ ràng.
Bài học rút ra: bộ giải mã chỉ có thể hiển thị những gì không được mã hóa - bộ giải mã ToolAcre JWT hiển thị tiêu đề và tải trọng của mã thông báo đã ký; Theo thiết kế, trọng tải của JWE không thể đọc được
Bộ giải mã chỉ có thể hiển thị những gì không được mã hóa. ToolAcre đọc JSON từ tiêu đề và tải trọng của đầu vào được ký gồm ba phần, trong khi năm phân đoạn gây ra điểm dừng có giải thích. Sự khác biệt đó ngăn cản giao diện chỉ giải mã giả vờ rằng nó có khả năng nhận.
Sử dụng số lượng phân đoạn làm đầu mối định tuyến chứ không phải kết quả tin cậy. Ba phần có thể đọc được vẫn yêu cầu xác minh chữ ký; năm phần được mã hóa yêu cầu giải mã và xác thực được ủy quyền. Trong cả hai trường hợp, đầu ra trực quan không xác thực được các xác nhận quyền sở hữu hoặc cấp quyền truy cập.