Báo cáo bài tập lớn môn mật mã học cơ sở về JWT

Báo cáo bài tập lớn môn mật mã học cơ sở ptit thầy Đỗ Xuân Chợ về. JWT JSON Web Tokens,JSON Web Token (JWT) là một chuỗi mã hoá hay một tiêu chuẩn mở (RFC 7519) được sử dụng như một phương tiện đại diện nhỏ gọn nhằm xác minh thông tin an toàn giữa các bên ClientServer dưới dạng JSON object. Thông tin này có thể được xác minh và tin cậy vì nó được ký điện tử digitally signed. JWT có thể được ký bằng cách sử dụng một secret (với thuật toán HMAC) hoặc cặp publicprivate key dùng chuẩn RSA hoặc ECDSA. JSON là một dạng dữ liệu được sử dụng theo một quy luật chung nhất định mà hầu hết các ngôn ngữ lập trình hiện nay đều có thể dễ dàng đọc và tìm hiểu. Nó được xem là một tiêu chuẩn mở với mục đích sử dụng là trao đổi dữ liệu trong website. Token: Đây là một chữ ký điện tử được mã hoá thành các con số khác nhau và các con số này tạo thành một dãy ấn tượng. Do được tạo dưới dạng OTP nên loại mã số này chỉ được tạo ngẫu nhiên và sử dụng một lần cho từng lần giao dịch khác nhau.

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

KHOA CÔNG NGHỆ THÔNG TIN I

-□□&□□ -BÁO CÁO BÀI TẬP

MÔN: MẬT MÃ HỌC CƠ SỞ

ĐỀ TÀI: JWT

GIẢNG VIÊN: TS ĐỖ XUÂN CHỢ

NHÓM THỰC HIỆN: NHÓM 011

Phan Tuấn Anh B18DCAT012

sss ssss ssss

Mục lục

Giới thiệu

Nội dung

I Khi nào nên dùng JSON Web Tokens?

II JWT bảo vệ dữ liệu của chúng ta bằng cách nào?

III Cấu trúc

IV Các thuật toán mã hoá

V JSON Web Tokens hoạt động như thế nào?

VI Các bước cơ bản để tạo JWT

VII Bài tập demo

Giới thiệu

JSON Web Token (JWT) là một chuỗi mã hoá hay một tiêu chuẩn mở (RFC 7519) được sử dụng như một phương tiện đại diện nhỏ gọn nhằm xác minh thông tin an toàn giữa các bên Client-Server dưới dạng JSON object Thông tin này có thể được xác minh và tin cậy vì nó được ký điện tử - digitally signed JWT có thể được ký bằng cách sử dụng một secret (với thuật toán HMAC) hoặc cặp

public/private key dùng chuẩn RSA hoặc ECDSA

JSON là một dạng dữ liệu được sử dụng theo một quy luật chung nhất định

mà hầu hết các ngôn ngữ lập trình hiện nay đều có thể dễ dàng đọc và tìm hiểu Nó được xem là một tiêu chuẩn mở với mục đích sử dụng là trao đổi dữ liệu trong website

Token: Đây là một chữ ký điện tử được mã hoá thành các con số khác nhau

và các con số này tạo thành một dãy ấn tượng Do được tạo dưới dạng OTP nên loại mã số này chỉ được tạo ngẫu nhiên và sử dụng một lần cho từng lần giao dịch khác nhau

Nội dung

I Khi nào nên dùng JSON Web Tokens?

Dưới đây là các lợi ích của việc sử dụng JWT:

● Uỷ quyền - Authorization: Đây là trường hợp nên sử dụng JWT Khi người dùng đã đăng nhập, mỗi request tiếp theo được gửi từ Client sẽ bao gồm JWT, cho phép người dùng access vào routes, services và resources được phép với token đó Single Sign ON là tính năng trong JWT được sử dụng rộng rãi hiện nay, vì chi phí thấp và dễ dàng sử dụng trên các domains khác nhau

● Trao đổi thông tin - Information Exchange: JSON Web Tokens là một cách tốt để truyền thông tin an toàn giữa các vên Client và Server Vì JWT có thể signed Ví dụ, sử dụng các cặp public/private key, bạn có thể biết ai là người gửi Ngoài ra, vì signature được xác định dựa vào header và payload, ta cũng có thể xác mình rằng nội dung chưa bị giả mạo

II JWT bảo vệ dữ liệu của chúng ta bằng cách nào?

Một điều quan trọng về JWT là không ẩn hay làm mờ dữ liệu theo bất

kỳ cách nào Lý do JWT được sử dụng là để chứng minh rằng dữ liệu được gửi thực sự được tạo ra bởi một nguồn xác thực

Dữ liệu bên trong JWT là mã hóa và được đánh dấu, hoặc không mã hóa Mục đích của việc mã hóa dữ liệu là chuyển đổi cấu trúc dữ liệu Dữ liệu đăng ký cho phép người nhận dữ liệu xác minh tích xác thực của nguồn

dữ liệu Vì vậy, mã hóa và đánh dấu dữ liệu KHÔNG bảo mật dữ liệu Mặc khác, mục đích chính của mã hóa là bảo mật dữ liệu và ngăn chặn truy cập trái phép

III Cấu trúc

JSON Web Tokens bao gồm 3 phần (Header, Payload, Signature) được phân tách bằng dấu `.`

JWT có dạng: xxxxx.yyyyy.zzzzz

Chuẩn format:

<base64-encoded header>.<base64-encoded

payload>.<HMACSHA256(base64-encoded signature)>

A Header

Trong Header gồm có 2 phần: Loại mã token và thuật toán được sử dụng

Ví dụ: Thuật toán là HS256, loại mã token là JWT

Sau đó JSON này được mã hoá Base64Url để tạo thành phần đầu tiên của JWT

B Payload

Phần thứ 2 của token là payload, nó chứa các Claims Claims thường chứa các thuộc tính như :typically, thông tin user và các dữ liệu bổ sung Có 3 loại claims: registered, public, và private claims

● Registered claims: Đây là một tập hợp các claims được xác định trước, không bắt buộc nhưng được khuyến nghị để có thể cung cấp một tập hợp các claims hữu ích, có thể tương tác

○ iss (issuer): tổ chức phát hành token (không bắt buộc)

○ sub (subject): chủ đề của token (không bắt buộc)

○ aud (audience): đối tượng sử dụng token (không bắt buộc)

○ exp (expired time): thời điểm token sẽ hết hạn (không bắt buộc)

○ nbf (not before time): token chưa hợp lên trước thời điểm này

○ iat (issued at): thời điểm token được phát hành, tính theo UNIX time

○ jti: JWT ID Lưu ý là claim names thường chỉ chứa 3 ký tự

● Public claims: Chúng có thể được xác định theo ý muốn của những người sử dụng JWT Để tránh xung đột, chúng ta phải được xác định trong IANA JSON Web Token Registry hoặc được định nghĩa là URI chứa namespace chống xung đột

● Private claims: Đây là các claims tuỳ chỉnh được tạo để chia sẻ thông tin giữa các bên đồng ý sử dụng chúng và không phải là các registered hay public claims

Ví dụ Payload có thể như sau:

Payload sau đó được mã hoá Base64Url để tạo thành phần thứ 2 của JSON Web Tokens

Lưu ý: Đối với các signed tokens, thông tin này, mặc dù được bảo vệ chống giả mạo nhưng mọi người đều có thể đọc được Không được đưa thông tin bảo mật các phần tử payload hoặc header của JWT trừ khi được mã hoá

C Signature

Để tạo signature ta cần phải lấy header được mã hoá, payload được

mã hoá, một secret, thuật toán được chỉ định trong header và sign Ví

dụ bạn dùng thuật toán HMAC SHA256, signature sẽ được tạo ra như sau:

Signature được sử dụng để xác minh tin nhắn không bị thay đổi trên đường truyền và trong trường hợp token được ký bằng private key,

nó cũng có thể xác mình người gửi JWT

IV Các thuật toán mã hoá

Có nhiều thuật toán mã hoá được sử dụng để tạo ra JWT, bao gồm các thuật toán mã hoá đối xứng (symmetric) và không đối xứng (asymmetric) Các thuật toán phổ biến nhất là HMAC, RSA và ECDSA

D HMAC (Hash-based Message Authentication Code): là một thuật toán

mã hoá đối xứng sử dụng một khoá bí mật để ký và xác thực dữ liệu HMAC tính toán chữ ký bằng cách sử dụng một hàm băm (hash function) và khoá bí mật Hàm băm được sử dụng phổ biến nhất là SHA-256 hoặc SHA-512

E RSA (Rivest-Shamir-Adleman): là một thuật toán mã hóa không đối xứng, sử dụng để mã hoá và khoá bí mật được sử dụng để giải mã RSA được sử dụng trong JWT để tạo ra chữ ký bằng cách sử dụng khoá bí mật Khoá công khai được sử dụng để xác thực chữ ký

F ECDSA (Elliptic Curve Digital Signature Algorithm): Là một thuật toán mã hóa không đối xứng dựa trên đường cong Elliptic ECDSA sử dụng một cặp khoá công khai và bí mật để tạo ra và xác thực chữ ký ECDSA có thể cung cấp độ bảo mật tương dương với RSA nhưng với một kích thước khoá nhỏ hơn

V JSON Web Tokens hoạt động như thế nào?

Trong xác thực, khi người dùng đăng nhập thành công bằng thông tin đăng

nhập của họ, JSON Web Token sẽ được trả về Vì token là thông tin xác thực, cần phải hết sức cẩn thận để ngăn chặn các vấn đề bảo mật Nói chung, bạn không nên giữ token lâu hơn yêu cầu

Bạn cũng không nên lưu trữ dữ liệu nhạy cảm trên session trong bộ nhớ trình duyệt do thiếu bảo mật

Bất cứ khi nào người dùng muốn truy cập route hoặc resource được bảo vệ, tác nhân người dùng nên gửi JWT, thêm Authorization trong header với nội dung

là Bearer + token Nội dung của header sẽ trông như sau:

Authorization: Bearer <token>

Máy chủ server sẽ kiểm tra tính hợp lệ của JWT trong header mỗi khi nhận request, nếu hợp lệ, người dùng sẽ được phép truy vấn cơ sở dữ liệu cho các hoạt động nhất định có thể bị giảm, mặc dù điều này có thể không phải luôn luôn như vậy

Nếu Token được gửi trong Authorization header, chia sẻ tài nguyên nguồn gốc chéo (Cross-Origin Resource Sharing - CORS) sẽ không thành vấn đề vì nó không sử dụng cookie

Sơ đồ sau đây cho thấy các JWT được lấy và sử dụng để truy cập API hoặc resource:

1 Application hoặc client requests authorization đến authorization server Điều này được thực hiện thông qua một trong các luồng authorization khác nhau

Ví dụ: Một ứng dụng web tuân thủ OpenID Connect điển hình sẽ đi qua / oauth / uỷ quyền điểm cuối bằng cách sử dụng luồng mã authorization

2 Khi authorization được cấp, authorization server sẽ trả lại access token cho

3 Application sẽ sử dụng access token để truy cập vào resource (như API)

Lưu ý: Với các signed tokens, tất cả thông tin trong token vẫn được hiển thị cho người dùng hoặc các bên khác, mặc dù họ không thể thay đổi thông tin đó Điều này có nghĩa là bạn không nên đặt thông tin bảo mật trong token

VI Các bước cơ bản để tạo JWT

JWT là một chuỗi có định dạng: header.payload.signature

G Bước 1: Tạo HEADER

Thành phần tiêu đề (header) dùng để khai báo chữ ký và thuật toán mã hóa sẽ dùng cho token Header là đối tượng JSON có định dạng:

Trong đoạn mã JSON, giá trị của khóa “typ” xác định rằng đối tượng là JWT và giá trị của khóa “alg” chỉ định thuật toán băm nào được sử dụng để tạo ra chữ ký (signature) cho JWT Trong ví dụ của mình, thuật toán được sử dụng là HMAC-SHA256, thuật toán băm sử dụng secret key để tính toàn chữ ký (signature)

H Bước 2: Tạo PAYLOAD

Phần thứ 2 của JWT là payload, nơi chứa các nội dung của thông tin Thông tin truyền đi có thể là mô tả của một thực thể hoặc cũng có thể là các thông tin bổ sung thêm cho phần header Nó được chia làm 3 loại: Registered, public, và private

Thành phần Payload của JWT là dữ liệu được lưu trữ bên trong JWT (dữ liệu này còn được gọi là “các xác nhận quyền sở hữu” của JWT) Trong ví dụ này, máy chủ xác thực tạo ra một JWT với thông tin người dùng được lưu trữ bên trong nó, đặc biệt là ID của người dùng

Trong ví dụ, ta chỉ đưa ra một xác nhận quyền sở hữu vào payload Bạn có thể đưa nhiều yêu cầu nếu bạn muốn Có một số tiêu chuẩn theo yêu cầu khác nhau cho payload JWT, chẳng hạn như “iss”,

“sub”, và “exp” Các trường này có thể được sử dụng khi tạo JWT

Lưu ý: Kích thước của dữ liệu sẽ ảnh hưởng đến kích thước tổng thể của JWT, điều này thường không phải là vấn đề nhưng nếu JWT quá lớn có thể ảnh hưởng tiêu cực đến hiệu suất và gây ra độ trễ

I Bước 3: Tạo Signature

Chữ ký (signature) được tính bằng cách sử dụng thuật toán sau:

Thuật toán này thực hiện bằng cách giải mã (header + payload) Thuật toán sau đó kết hợp các chuỗi được mã hóa kết quả cùng với dấu chấm (.) ở giữa chúng Trong đoạn mã, chuỗi nối này được gán cho data Chuỗi dữ liệu được băm bằng secret key sử dụng thuật toán băm được chỉ định trong tiêu đề JWT Kết quả dữ liệu băm được gán cho hashedData Dữ liệu băm này sau đó được mã hóa base64url để tạo ra chữ ký (signature) JWT

Trong ví dụ, cả header và payload được mã hóa Base64Url

Sau đó, áp dụng thuật toán signature với secret key trên, header và payload được mã hóa và ghép nối với nhau, chúng ta nhận được dữ liệu được băm cung cấp cho signature Trong TH của chúng ta, điều này có nghĩa là áp dụng thuật toán HS256, với secret key là "secret" trên chuỗi dữ liệu để nhận được chuỗi hashedData Sau đó, thông qua base64url mã hóa chuỗi hashedData, chúng ta nhận được chữ ký của JWT như sau:

J Bước 4: Kết hợp 3 thành phần JWT với nhau

Sau khi tạo cả 3 thành phần, chúng ta có thể tạo JWT Cấu trúc của JWT: HEADER.PAYLOAD.SIGNATURE, chúng ta chỉ cần kết hợp các thành phần, với dấu chấm (.) để phân cách chúng Chúng ta

sử dụng phiên bản được mã hóa base64 của header, payload và

signature được tạo ở trên

VD: JWT Token

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMD hmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ

.-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

K Bước 5: Xác thực mã JWT

Trong ví dụ về 3 thực thể đơn giản, chúng ta đang sử dụng JWT được đăng ký bởi thuật toán HS256, nơi chỉ có máy chủ xác thực và máy chủ ứng dụng mới biết được mã secret Máy chủ ứng dụng nhận key secret từ máy chủ xác thực khi ứng dụng thiết lập quá trình xác thực Từ khi ứng dụng biết được secret key, khi người dùng thực hiện các cuộc gọi API đính kèm JWT vào ứng dụng, ứng dụng có thể thực hiện cùng một thuật toán signature như trong Bước 3 trên JWT Sau

đó, ứng dụng có thể xác minh rằng signature thu được từ việc thực

hiện băm của chính nó khớp với signature trên chính JWT (nghĩa là khớp với signature JWT được tạo ra bởi máy chủ xác thực) Nếu signature khớp với nhau, thì điều đó có nghĩa là JWT hợp lệ, cuộc gọi API đến từ một nguồn xác thực Nếu signature không khớp, thì có nghĩa là JWT nhận được không hợp lệ, có thể là dấu hiệu của một tấn công tiềm tàng trên ứng dụng Vì vậy bằng cách xác minh JWT, ứng dụng sẽ thêm một lớp tin cậy giữa chính nó và người dùng

VII Bài tập demo

Setup redis

Setup mariadb

Login API

Lấy JWT lưu trong redis

Decode JWT

Mã permission