luận văn tốt nghiệp secure socket layer (bảo mật thông tin)

SSL giải quyết các vấn đề trên.SSL giải quyết vấn đề đầu tiên bằng cách cho phép 1 cách tùy chọn mỗi bên trao đổi có thể chắc chắn về định danh của phía đối tác trong 1 quá trình gọi là

Giáo viên hướng dẫn : Ths.Lê Phúc

Sinh viên thực hiện : Huỳnh Anh Hào

MỤC LỤC

Giới Thiệu

CHƯƠNG I : SECURE SOCKET LAYER & TRANSPORT LAYER SECURITY 5

I.1 Tại sao sử dụng SSL 5

I.2 Kiến trúc SSL 9

I.3 Giao thức SSL Record 10

I.4 Giao thức SSL Change Cipher Spec 13

I.5 Giao thức SSL Alert 13

I.6 Giao thức SSL Handshake 15

I.6.1 Giai đoạn 1 : Thiết lập khả năng bảo mật 16

I.6.2 Giai đoạn 2 : Xác thực server và trao đổi khóa 18

I.6.3 Giai đoạn 3 : Xác thực client và trao đổi khóa 19

I.6.4 Giai đoạn 4 : Kết thúc 19

I.7 Tính toán mã hóa 20

I.7.1 Việc tạo Master Secret 20

I.7.2 Việc sinh các tham số mã hóa 21

I.8 Transport Layer Security 22

I.8.1 Version number 22

I.8.2 Message Authentication Code 22

I.8.3 Hàm tính số ngẫu nhiên 23

I.8.4 Mã cảnh báo 24

I.8.5 Cipher suite 25

I.8.6 Các dạng client certificate 25

I.8.7 Certificate Verify và Finished Message 26

I.8.8 Tính toán mã hóa 26

I.8.9 Phần đệm 26

CHƯƠNG II : JAVA SECURE SOCKET EXTENSION API 27

II.1 Quan hệ giữa các Class 27

II.2 Các Class và Interface chính 28

II.2.1 Lớp SocketFactory và ServerSocketFactory 28

II.2.2 Lớp SSLSocketFactory và SSLServerSocketFactory 28

II.2.3 Lớp SSLSocket và SSLServerSocket 29

II.2.4 Non-blocking I/O với SSLEngine 30

II.2.5 Quá trình khởi động 31

II.2.6 Phát sinh và xử lý dữ liệu SSL/TLS 32

II.2.7 Trạng thái hoạt động 34

II.2.8 Blocking Tasks 35

II.2.9 Kết thúc 35

II.2.10 SSLSession Interface 36

II.2.11 Lớp HttpsURLConnection 36

II.3 Các Class và Interface hỗ trợ 37

II.3.1 Lớp SSLContext 38

II.3.2 TrustManager Interface 39

II.3.3 Lớp TrustManagerFactory 39

II.3.4 X509TrustManager Interface 42

II.3.5 KeyManager Interface 44

II.3.6 Lớp KeyManagerFactory 45

II.3.7 X509KeyManager Interface 46

II.3.8 Mối liên hệ TrustManagers và KeyManagers 46

II.4 Các Class và Interface hỗ trợ thứ cấp 47

II.4.1 SSLSessionContext Interface 47

II.4.2 SSLSessionBindingListener Interface 47

II.4.3 Lớp SSLSessionBindingEvent 47

II.4.4 HandShakeCompletedListener Interface 47

II.4.5 Lớp SSLHandShakeCompletedEvent 47

II.4.6 HostnameVerifier Interface 47

II.4.7 Lớp X509Certificate 48

CHƯƠNG III : SSL ATTACK 49

III.1 Các phương pháp tấn công SSL dựa trên kỹ thuật tấn công MITM 49

III.1.1 Diffie Hellman MITM Attack 49

III.1.2 SSL Sniff & SSLSTrip MITM Attack 46

III.2 Demo tấn công SSL Strip 51

CHƯƠNG IV : SSL CAPABILITY 52

IV.1 Các ứng dụng phổ biến của SSL 52

IV.2 Triển khai SSL 54

Tham khảo

Giới thiệu :

Mục tiêu thực hiện đề tài này của những thành viên tham gia là đi sâu tìm hiểu về :

 Cấu trúc cũng như cơ chế hoạt động của SSL

 Lập trình xây dựng một web server chạy SSL

 Cách thức tấn công một phiên giao dịch SSL

 Khả năng ứng dụng SSL trong bảo mật thông tin

Đây là lần đầu thực hiện một đề tài lớn nên còn nhiều thiếu sót , mong Thầy và các bạn đóng góp ý kiến để đề tài được hoàn thiện hơn

Chúng em xin cảm ơn sự hướng dẫn nhiệt tình của Thầy Ths.Lê Phúc đã giúp chúng em hoàn thành đề tài này

Chương I :

I.1 Tại sao sử dụng SSL :

Ngày nay việc bảo mật thông tin là yếu tố quan trọng để quyết định sự sống còn của một tổ chức ,một công ty hay doanh nghiệp Với sự phát triển nhanh chóng của công nghệ đã mang lại nhiều tiện ích cho người dùng nhưng đồng thời cũng đặt ra một nhu cầu hết sức cấp thiết về sự an toàn và bảo mật Và SSL chính là giải pháp tốt nhất hiện nay đáp ứng những nhu cầu đó và nó được coi như là “lá chắn cuối cùng” trong bảo mật thương mại điện tử

Giao thức SSL ban đầu được phát triển bởi Netscape.Version 1.0 thì đã không bao giờ được công bố rộng

rãi.Version 2.0 được công bố vào tháng 2/1995 nhưng chứa nhiều lỗ hỏng bảo mật và sau cùng đưa đến mô hình SSL version 3.0 được ban hành năm 1996.Bản sau cùng này được dùng cho TLS version 1.0 và được IETF xác định như một giao thức chuẩn trong RFC 2246 vào tháng 1/1999 Ngày nay Visa, MasterCard, American Express cũng như nhiều công ty giải pháp tài chính hàng đầu khác trên thế giới đã và đang ứng dụng SSL trong thương mại điện

tử

Việc truyền các thông tin nhạy cảm trên mạng rất không an toàn vì những vấn đề sau:

Bạn không thể luôn luôn chắc rằng bạn đang trao đổi thông tin với đúng đối tượng cần trao đổi

Dữ liệu mạng có thể bị chặn ,vì vậy dữ liệu có thể bị 1 đối tượng thứ 3 khác đọc trộm, thường được biết đến như attacker

Nếu attacker có thể chặn dữ liệu, attacker có thể sửa đổi dữ liệu trước khi gửi nó đến người nhận

SSL giải quyết các vấn đề trên.SSL giải quyết vấn đề đầu tiên bằng cách cho phép 1 cách tùy chọn mỗi bên trao đổi

có thể chắc chắn về định danh của phía đối tác trong 1 quá trình gọi là authentication (xác thực).Một khi các bên đã được xác thực,SSL cung cấp 1 kết nối được mã hóa giữa 2 bên để truyền bảo mật các message Việc mã hóa trong quá trình trao đổi thông tin giữa 2 bên cung cấp sự riêng tư bí mật,vì vậy mà giải quyết được vấn đề thứ 2.Thuật toán mã hóa được sử dụng với SSL bao gồm hàm băm mã hóa,tương tự như 1 checksum.Nó đảm bảo rằng dữ liệu không bị thay đổi trong quá trình truyền dẫn.Hàm băm mã hóa giải quyết vấn đề thứ 3,tính toàn vẹn dữ liệu

Chú ý rằng,cả xác thực và mã hóa đều là tùy chọn, và phụ thuộc vào cipher suites (các bộ mã hóa) được đàm phán giữa 2 đối tượng

Một ví dụ rõ ràng nhất mà trong đó bạn nên sử dụng SSL là trao đổi thông tin giao dịch qua mạng

(e-commerce).Trong trao đổi e-commerce,thật dại dột khi giả định rằng bạn có thể chắc chắn về định danh của server

mà bạn đang trao đổi thông tin.Ai đó có thể dễ dàng tạo ra 1 Website giả hứa hẹn các dịch vụ tuyệt vời ,chỉ để cho bạn nhập vào đó số tài khoản.SSL cho phép bạn, client,xác thực về định danh của server.Nó cũng cho phép server xác thực định danh của client,mặc dù trong các giao tác Internet,việc này hiếm khi được làm

Một khi client và server đã hài lòng với định danh của mỗi bên đối tác.SSL cung cấp tính bảo mật và tính toàn vẹn thông qua các thuật toán mã hóa mà nó sử dụng.Điều này cho phép các thông tin nhạy cảm,như số tài khoản,được truyền đi 1 cách an toàn trên Internet

Trong khi SSL cung cấp tính xác thực,tính bảo mật và toàn vẹn dự liệu,nó không cung cấp non-repudiation (tính không từ chối).Non-repudiation có nghĩa là khi 1 đối tượng gửi đi 1 message ,thì sau đó không thể phủ nhận việc mình đã gửi message đó.Khi 1 chữ kí số tương đương được liên kết với 1 message,việc trao đổi này sau đó có thể được chứng minh.SSL 1 mình nó không cung cấp non-repudiation

Xác thực server :

Trong SSL,bước xác thực là tùy chọn,nhưng trong ví dụ về giao tác e-commerce trên Web, client theo thông thường

sẽ muốn xác thực server.Việc xác thực server cho phép client chắc chắn rằng chính server này đại diện cho đối tượng mà client tin tưởng

Để chứng minh server thuộc về tổ chức mà nó khẳng định là nó đại diện,server phải trình chứng chỉ khóa công khai của nó cho client.Nếu chứng chỉ này là hợp lệ ,client có thể chắc chắn về định danh của server

Thông tin trao đổi qua lại giữa client và server cho phép chúng thỏa thuận 1 khóa bí mật chung.Ví dụ,với

RSA,client dùng khóa công khai của server,có được từ chứng chỉ khóa công khai, để mã hóa thông tin khóa bí mật.Client gửi thông tin khóa bí mật đã được mã hóa đến server.Chỉ có server mới có thể giải mã cái message này bởi vì quá trình giải mã phải cần đến khóa riêng của server

Gửi dữ liệu đã mã hóa:

Bây giờ,cả client và server có thể truy cập đến khóa bí mật chung.Với mỗi message ,chúng dùng đến hàm băm mã hóa,đã được chọn trong bước thứ nhất của tiến trình này,và chia sẻ thông tin bí mật,để tính toán 1 HMAC nối thêm vào message.Sau đó,chúng dùng khóa bí mật và thuật toán khóa bí mật đã được đàm phán ở bước đầu tiên của tiến trình này để mã hóa dữ liệu và HMAC an toàn.Client và server giờ đây có thể trao đổi thông tin với nhau 1 cách an toàn với các dữ liệu đã băm và mã hóa

Giao thức SSL:

Phần trước cung cấp sự mô tả sơ lược về SSL handshake, là sự trao đổi thông tin giữa client và server trước khi gửi các message đã được mã hóa.Phần này mô tả chi tiết hơn.Hình sau minh họa chuỗi tuần tự các message được trao đổi trong SSL handshake.Các message mà chỉ được gửi trong 1 trường hợp nào đó được đánh dấu là tùy chọn

Hình II: Các message SSL

Các message SSL được gửi theo thứ tự sau:

1) Client hello: client gửi đến server các thông tin bao gồm phiên bản SSL cao nhất và 1 danh sách các cipher

suite mà nó hỗ trợ (TLS 1.0 được chỉ ra như là SSL3.1).Thông tin cipher suite bao gồm các thuật toán mã hóa và kích thước khóa

2) Server hello: server chọn ra phiên bản SSL cao nhất và cipher suite tốt nhất mà cả client và server hỗ trợ,

và gửi thông tin này về cho client

3) Certificate: server gửi cho client 1 chứng chỉ hoặc 1 chuỗi chứng chỉ.Về cơ bản,1 chuỗi chứng chỉ bắt đầu

bằng chứng chỉ khóa công khai của server và kết thúc bằng chứng chỉ gốc của tổ chức có thẩm quyền chứng chỉ.Message này là tùy chọn,nhưng nó được dùng bất cứ khi nào xác thực server là cần thiết

4) Certificate request: nếu server cần xác thực client,nó gửi cho client 1 yêu cầu xem chứng chỉ.Trong các

ứng dụng internet,message này hiếm khi được gửi đi

1.Client hello

7.Certificate tùy chọn

8.Client key exchange

9.Certificate verify tùy chọn

10.Change cipher spec

6.Server hello done

12.Change cipher spec 13.Finished

14.Encrypted data 15.Close message

5) Server key exchange: server gửi cho client 1 message trao đổi khóa server trong khi khóa công khai được

gửi ở phần 3) bên trên thì không đủ cho trao đổi khóa

6) Server hello done: server nói với client rằng nó hoàn thành các message đàm phán ban đầu

7) Certificate: nếu server cần chứng chỉ từ client trong message 4, client gửi chuỗi chứng chỉ của nó,cũng

giống như server làm trong message 3

8) Client key exchange: client sinh ra thông tin được dùng để tạo ra khóa trong mã hóa đối xứng.Với RSA,

client mã hóa thông tin khóa này bằng khóa công khai của server rồi gửi nó đến server

9) Certificate verify: message này được gửi khi client trình ra chứng chỉ như trên.Mục tiêu của nó là cho phép

server hoàn thành tiến trình xác thực client.Khi message này được dùng,client gửi thông tin với chữ kí số tạo bằng hàm băm mã hóa.Khi server giải mã thông tin này bằng khóa công khai của client,server có thể xác thực client

10) Change cipher spec: client gửi message bảo server thay đổi kiểu mã hóa

11) Finished: client nói với server rằng nó sẵn sàng để bắt đầu trao đổi dữ liệu an toàn

12) Change cipher spec: server gửi message bảo client thay đổi kiểu mã hóa

13) Finished: server nói với client rằng nó sẵn sàng để bắt đầu trao đổi dữ liệu an toàn.Kết thúc SSL

handshake

14) Encrypted data: client và server trao đổi với nhau,sử dụng thuật toán mã hóa đối xứng và hàm băm mã hóa

đã đàm phán ở message 1 và 2,và dùng khóa bí mật mà client gửi cho server trong message 8

15) Closed messages : Kết thúc 1kết nối,mỗi bên gửi 1 message close-notify để thông báo đầu kia biết kết nối

bị đóng

Nếu các tham số được sinh ra trong 1 phiên SSL được lưu lại,các tham số này có thể thỉnh thoảng được dùng lại cho các phiên SSL sau.Việc lưu lại các tham số phiên SSL cho phép các trao đổi bảo mật về sau được bắt đầu nhanh chóng hơn

Lựa chọn Cipher suite và xóa Entity verification:

Giao thức SSL/TLS định nghĩa 1 chuỗi các bước đặc biệt để bảo đảm 1 kết nối “được bảo vệ”.Tuy nhiên,việc lựa chọn Cipher suite sẽ tác động trực tiếp đến loại bảo mật mà kết nối có được.Ví dụ,nếu 1 cipher suite nặc danh được chọn,ứng dụng không có cách nào để kiểm tra định danh của đầu xa.Nếu 1 suite-không có mã hóa, được chọn,tính

bí mật của dữ liệu không thể được bảo vệ.Thêm vào đó,giao thức SSL/TLS không chỉ rõ rằng những tài liệu chứng nhận nhận được phải khớp với những cái mà đầu kia gửi.Nếu kết nối theo cách nào đó mà bị redirect đến 1 kẻ xấu,nhưng tài liệu chứng nhận của kẻ xấu này khi trình ra thì được chấp nhận dựa trên những tư liệu tin tưởng hiện tại,kết nối này sẽ được xét là hợp lệ

Khi dùng SSLSockets/SSLEngines,nên luôn luôn kiểm tra tài liệu chứng nhận của đầu xa trước khi gửi bất kì dữ liệu nào.Các lớp SSLSockets và SSLEngines không tự động kiểm tra hostname trong URL có khớp với hostname trong

tài liệu chứng nhận của đầu kia hay không.Một ứng dụng có thể bị khai thác bằng URL spoofing nếu hostname không được kiểm tra

Các giao thức như HTTPS cần thiết phải kiểm tra hostname.Các ứng dụng có thể dùng HostnameVerifier để viết

chồng lên luật hostname HTTPS mặc định

SSL Change Cypher Spec Protocol

SSL Alert Protocol HTTP

SSL Record Protocol

TCP

IP

SSL Record Protocol cung cấp các dịch vụ bảo mật cơ bản cho nhiều giao thức khác nhau ở các lớp trên.Trong thực

tế, Hyper Text Transfer Protocol (HTTP),cung cấp dịch vụ trao đổi cho tương tác Web client/server,có thể hoạt động trên đỉnh của SSL.Ba giao thức lớp trên được định nghĩa như là các phần của SSL: Handshake Protocol, Change Cypher Spec Protocol và Alert Protocol.Các giao thức mang tính đặc trưng-SSL này được dùng trong phần quản lý trao đổi SSL và được xét đến trong phần sau

Hai khái niệm SSL quan trọng là SSL session (phiên SSL) và SSL connection ( kết nối SSL) ,được định nghĩa như sau:

Connection ( kết nối): 1 kết nối là 1 transport _ trong định nghĩa mô hình phân lớp OSI_ cung cấp 1 loại

dịch vụ thích hợp.Với SSL,những kết nối như vậy là những mối quan hệ ngang hàng.Các kết nối thì trao đổi nhanh chóng.Mỗi kết nối gắn với 1 phiên

Session (phiên): 1 phiên SSL là 1 liên kết giữa 1 client và 1 server.Các phiên được tạo ra bằng Handshake

Protocol (giao thức bắt tay).Các phiên định nghĩa 1 tập các tham số bảo mật bằng mật mã,có thể được chia

sẻ giữa nhiều kết nối.Các phiên được dùng để tránh những đàm phán tốn kém_về các tham số bảo mật mới_cho mỗi kết nối

Giữa bất kì 1 cặp của nhóm nào (các ứng dụng như HTTP trên client hay server),có thể có nhiều kết nối bảo mật Về lý thuyết ,có thể có nhiều phiên đồng thời giữa các nhóm,nhưng đặc trưng này không được dùng trong thực tiễn Thực sự có nhiều trạng thái gắn với mỗi phiên.Một khi 1 phiên được thành lập,có trạng thái hoạt động hiện thời cho

cả đọc và ghi, (như nhận và gửi ).Thêm vào đó, trong suốt quá trình Handshake Protocol, trạng thái treo đọc và ghi được tạo ra.Dựa trên kết luận thành công của Handshake Protocol,các trạng thái treo trở thành trạng thái hiện thời -Một trạng thái phiên được định nghĩa bởi các thông số sau (các định nghĩa lấy từ đặc trưng SSL):

Session Identifier : 1 chuỗi byte bất kì được chọn bởi server để nhận dạng trạng thái phiên là hoạt động

(active) hay phục hồi lại (resumable)

Peer certificate: một chứng chỉ X509.v3.Thành phần này của trạng thái có thể là null

Compression method: thuật toán được dùng để nén dữ liệu trước khi mã hóa

Cypher spec : chỉ ra thuật toán mã hóa dữ liệu (như rỗng,AES…) và thuật toán băm (như MD5 hay

SHA-1) sử dụng để tính toán MAC.Nó cũng định nghĩa các thuộc tính mã hóa như hash-size

Master secret : 48 byte bí mật được chia sẻ giữa client và server

Is resumable : một cờ chỉ ra rằng phiên này có thể được dùng để khởi tạo các kết nối khác hay không

-Một trạng thái kết nối được định nghĩa bởi các tham số sau:

Server and client random: các chuỗi byte được chọn bởi server và client cho mỗi kết nối

Server write MAC secret: khóa bí mật được sử dụng bởi phép tính MAC trên dữ liệu, được gửi bởi server Client write MAC secret: khóa bí mật được sử dụng bởi phép tính MAC trên dữ liệu,được gửi bởi client Server write key: khóa mã hóa quy ước cho dữ liệu được mã hóa bởi server và giải mã bởi client

Client write key :khóa mã hóa quy ước cho dữ liệu được mã hóa bởi client và giải mã bởi server

Initialization vectors: khi 1 khối mã trong mode CBC được dùng, một vector khởi tạo (IV) được duy trì

cho mỗi key.Phần này được khởi tạo trước tiên bởi SSL Handshake Protocol.Sau đó,khối mã hóa cuối cùng

từ mỗi record được để dành lại để dùng làm IV cho record sau

Sequence number : mỗi bên duy trì các sequence number riêng cho mỗi message được truyền hoặc được

nhận trong mỗi kết nối.Khi 1 bên gửi hoặc nhận một change cypher spec message,sequence number thích hợp được thiết lập về 0.Sequence number không thể vượt quá 264

-1

I.3 Giao thức SSL Record :

SSL Record Protocol cung cấp 2 dịch vụ cho kết nối SSL:

Confidentiality (tính cẩn mật): Handshake Protocol định nghĩa 1 khóa bí mật được chia sẻ, khóa này được

sử dụng cho mã hóa quy ước các dữ liệu SSL

Message integrity (tính toàn vẹn thông điệp):Handshake Protocol cũng định nghĩa 1 khóa bí mật được chia

sẻ, khóa này được sử dụng để hình thành MAC (mã xác thực message)

Hình sau chỉ ra toàn bộ hoạt động của SSL Record Protocol.SSL Record Protocol nhận 1 message ứng dụng sắp được truyền đi,phân mảnh dữ liệu thành nhiều block,nén dữ liệu 1 cách tùy chọn,áp dụng vào 1 MAC,mã hóa,thêm vào header,và truyền khối kết quả thu được trong 1 segment TCP.Dữ liệu nhận được được giải mã,kiểm tra ,giải nén,sắp xếp lại và phân phối đến người sử dụng ở lớp cao hơn

Hình I.2 : Hoạt động của SSL Record Protocol

Bước đầu tiên là phân mảnh.Mỗi message của lớp bên trên được phân mảnh thành các block ,mỗi block là 214

byte (16384 byte) hoặc ít hơn

Tiếp theo,nén được áp dụng 1 cách tùy chọn.Nén phải là không mất mát thông tin và có thể không làm tăng chiều

dài nội dung nhiều hơn 1024 byte (Dĩ nhiên,người ta mong muốn nén làm co lại dữ liệu hơn là nới rộng dữ liệu.Tuy nhiên ,với những block ngắn,có thể ,do định dạng quy ước,thuật toán nén thực sự làm cho output dài hơn

input).Trong SSLv3 (cũng như phiên bản hiện tại của TLS),không có thuật toán nén nào được chỉ rõ,vì vậy thuật toán nén mặc định là null

Bước xử lí kế tiếp là tính toán MAC (mã xác thực message) trên dữ liệu đã được nén.Để thực hiện cần dùng đến1

khóa bí mật được chia sẻ.Phép tính được định nghĩa như sau:

hash(MAC_write_secret || pad_2 || hash(MAC_write_secret || pad_1 ||seq_num ||SSLCompressed.type ||

SSLCompressed.length || SSLCompressed.fragment))

trong đó:

 || : phép nối/hoặc

 MAC_write_secret: khóa bí mật được chia sẻ

 hash: thuật toán băm mã hóa, MD5 hoặc SHA-1

 pad_1: byte 0x36 (0011 0110) được lặp lại 48 lần (384 bit) cho MD5 và 40 lần (320 bit) cho SHA-1

 pad_2: byte 0x5c (0101 1100) được lặp lại 48 lần cho MD5 và 40 lần cho SHA-1

 seq_num: sequence number cho message này

 SSLCompressed.type: giao thức ở lớp trên được dùng để xử lí phân mảnh này

 SSLCompressed.length: chiều dài của phân mảnh đã được nén

 SSLCompressed.fragment: phân mảnh đã được nén (nếu nén không được dùng, phân mảnh ở dạng

plaintext)

Chú ý rằng,cái này tương tự như thuật toán HMAC.Điểm khác biệt là 2 phần đệm (pad) được || trong SSLv3 và được XOR trong HMAC.Thuật toán MAC trong SSLv3 được dựa trên bản phác thảo Internet ban đầu cho

HMAC.Phiên bản gần nhất của HMAC được định nghĩa trong RFC 2104,sử dụng XOR

Kế tiếp, message đã nén cộng thêm MAC được mã hóa theo phương pháp mã hóa đối xứng.Mã hóa có thể

không làm tăng chiều dài nội dung hơn 1024 byte,vì vậy chiều dài tổng cộng không vượt quá 214+2048 Các thuật toán mã hóa sau được cho phép:

Block cipher (Mã hóa khối) Stream cipher (Mã hóa luồng)

Thuật toán Kích thước khóa Thuật toán Kích thước khóa

Fortezza có thể được sử dụng trong mục tiêu mã hóa smart card

Với mã hóa stream (luồng),message đã nén cộng thêm MAC được mã hóa.Chú ý rằng MAC được tính toán trước khi mã hóa xảy ra và MAC được mã hóa cùng với plaintext hoặc là plaintext đã nén

Với mã hóa block (khối),MAC có thể được đệm thêm trước khi mã hóa.Phần đệm thêm (padding) có dạng gồm nhiều byte đệm được theo sau bởi 1 byte chỉ rõ chiều dài của phần đệm.Tổng số lượng đệm vào là lượng nhỏ nhất sao cho tổng kích thước dữ liệu được mã hóa (plaintext +MAC + padding) là 1 bội số của chiều dài khối mã hóa.Ví

dụ, plaintext (hoặc text đã nén nếu nén được dùng) là 58 byte, với MAC là 20 byte (dùng SHA-1), được mã hóa với chiều dài block là 8 byte (như DES ).Cùng với byte padding.length ,nó sinh ra tổng cộng 79 byte.Để tạo ra 1 số nguyên là bội của 8,1 byte đệm được thêm vào

Bước cuối cùng của xử lí SSL Record Protocol là gắn thêm vào1 header ,bao gồm các mục sau:

Content Type (8 bit): giao thức lớp trên được dùng để xử lí phân mảnh đi kèm

Major Version (8 bit): chỉ ra phiên bản SSL tối đa được dùng Ví dụ, SSLv3,giá trị này là 3

Minor Version (8 bit) : chỉ ra phiên bản tối thiểu được dùng.Ví dụ, SSLv3 ,giá trị này là 0

Compressed Length (16 bit) : chiều dài theo byte của phân mảnh plaintext (hoặc chiều dài theo byte của

phân mảnh đã nén nếu nén được dùng).Gía trị lớn nhất là 214

+2048

Các loại nội dung được định nghĩa là change_cipher_spec,alert,handshake, và application_data.Ba cái đầu tiên là các giao thức đặc trưng-SSL,được bàn đến trong phần kế tiếp.Chú ý rằng không có sự khác biệt nào được tạo ra giữa các ứng dụng (như HTTP ) có thể dùng SSL,nội dung dữ liệu được tạo ra bởi các ứng dụng đó thì không trong suốt đối với SSL

Hình sau minh họa định dạng SSL record

I.4 Giao thức SSL Change Cipher Spec :

Giao thức SSL Change Cipher Spec là giao thức đơn giản nhất trong ba giao thức đặc trưng của SSL mà sử dụng giao thức SSL Record Giao thức này bao gồm một message đơn 1 byte giá trị là 1 Mục đích chính của message này là sinh ra trạng thái tiếp theo để gán vào trạng thái hiện tại,và trạng thái hiện tại cập nhật lại bộ mã hóa để sử dụng trên kết nối này

I.5 Giao thức SSL Alert :

Giao thức SSL Alert được dùng để truyền cảnh báo liên kết SSL với đầu cuối bên kia.Như với những ứng dụng khác sử dụng SSL, alert messages được nén và mã hóa, được chỉ định bởi trạng thái hiện tại

Mỗi message trong giao thức này gồm 2 bytes Byte đầu tiên giữ giá trị cảnh báo(1) hoặc nguy hiểm(2) để thông báo độ nghiêm ngặt của message.Nếu mức độ là nguy hiểm,SSL lập tức chấp dứt kết nối.Những kết nối cùng phiên khác vẫn có thể tiếp tục nhưng sẽ không kết nối nào khác trên phiên này được khởi tạo thêm.Byte thứ hai chứa một

mã chỉ ra cảnh báo đặc trưng.Đầu tiên , chúng ta liệt kê những cảnh báo đó mà luôn ở mức nguy hiểm ( được định nghĩa từ những thông số SSL):

unexpected_message: message không thích hợp

bad_record_mac: MAC không chính xác

decompression_failure: việc giải nén nhận input không thích hợp(ví dụ như không thể giải nén hoặc giải

nén lớn hơn độ dài tối đa cho phép)

handshake_failure: bên gửi không thể thương lượng một bộ chấp nhận được của các thông số bảo mật

được đưa ra từ những lựa chọn có sẵn

illegal_parameter: một trường trong một handshake message thì vượt khỏi dãy hoặc trái với những trường

khác

Phần còn lại của cảnh báo thì như sau:

close_notify: thông báo cho bên nhận rằng bên gửi sẽ không gửi thêm message nào nữa trong kết nối

này.Mỗi nhóm thì được yêu cầu gửi một close_notify cảnh báo trước khi kết thúc phần ghi của một kết nối

no_certificate: có thể được gửi để trả lời cho một yêu cầu certificate nếu không certificate thích hợp nào có

sẵn

bad_certificate: certificate nhận được thì không hợp lệ(ví dụ như chứa một chữ ký không xác minh)

unsupported_certificate: dạng certificate nhận được thì không hỗ trợ

certificate_revoked: certificate đã bị thu hồi bởi nhà cung cấp

certificate_expired: certificate đã hết hạn đăng ký

certificate_unknown: một số phát sinh không nói rõ xuất hiện trong quá trình xử ký certificate làm cho nó

không thể chấp nhận

I.6 Giao thức SSL Handshake :

Phần „khó nuốt‟ nhất của SSL là giao thức Handshake.Giao thức này cho phép server và client chứng thực với nhau

và thương lượng cơ chế mã hóa , thuật toán MAC và khóa mật mã được sử dụng để bảo vệ dữ liệu được gửi trong SSL record.Giao thức SSL Handshake thường được sử dụng trước khi dữ liệu của ứng dụng được truyền đi Giao thức SSL Handshake bao gồm một loạt những message trao đổi giữa client và server Mỗi message có ba trường:

Type (1 byte): chỉ ra một trong mười dạng message

Length (3 bytes): độ dài của message theo bytes

Content (>=0 bytes): tham số đi kèm với message này, được liệt kê trong Hình I.5a

Hình I.5a Các kiểu message giao thức SSL handshake

Client_hello version, random, session id, cipher suite, compression

method Server_hello version, random, session id, cipher suite, compression

method Certificate chain of X.509v3 certificates

Server_key_exchange parameters, signature

Certificate_request type, authorities

Certificate_verify signature

Client_key_exchange parameters, signature

Hình I.5b thể hiện trao đổi lúc ban đầu cần được thiết lập một kết nối logic giữa client và server.Việc trao đổi có thể xem như có bốn giai đoạn

Hình I.5b Cơ chế giao thức SSL Handshake

I.6.1 Giai đoạn 1 – Thiết lập khả năng bảo mật :

Giai đoạn này được dung để bắt đầu một kết nối logic và thiết lập khả năng bảo mật mà sẽ liên kết với nó.Việc trao đổi thì được khởi tạo bởi client bằng việc gửi một client_hello message với những thông số sau đây:

Version: version SSL mới nhất mà client biết

Random: một cấu trúc sinh ra ngẫu nhiên từ client, bao gồm một nhãn thời gian 32 bit và 28 bytes sinh bởi

một bộ sinh số ngẫu nhiên an toàn Những giá trị này phục vụ cho lần này và sử dụng suốt quá trình trao đổi khóa để ngăn tấn công lập lại

Session ID: một ID của phiên có chiều dài thay đổi được.SessionID khác 0 nghĩa là client muốn cập nhật

tham số của một kết nối đang tồn tại hay tạo một kết nối mới trên phiên này.SessionID = 0 chỉ ra rằng client muốn thiết lập một kết nối mới trên một phiên mới

CipherSuite: đây là 1 danh sách mà chứa những bộ biên dịch của những thuật toán mã hóa được hỗ trợ bởi

client, tham khảo theo thứ tự giảm dần Mỗi thành phần trong danh sách (mỗi bộ mã hóa) định nghĩa cả một khóa trao đổi và một CipherSpec, những thông số này sẽ được bàn đến sau

Compression Method: đây là danh sách của những phương thức nén mà client hỗ trợ

Sau khi gửi client_hello message, client chờ nhận server_hello message mà chứa cùng thông số với client_hello message.Với server_hello message, những thỏa thuận kèm theo được áp dụng Trường Version chứa version thấp hơn được đề nghị bởi client và cao nhất được hổ trợ bởi sever.Trường Random được sinh ra bởi server và độc lập với trường Random của client Nếu trường SessionID của client khác 0, thì giá trị tương tự được dùng bởi server, ngược lại thì trường SessionID của server chứa giá trị của một phiên mới Trường CipherSuite chứa bộ mã hóa chọn bởi server từ những đề xuất của client Trường Compression chứa phương thức nén chọn bởi server từ những đề xuất của client

Thành phần đầu tiên của thông số Cipher Suite là phương thức trao đổi khóa (ví dụ như bằng cách nào những khóa

mã hóa cho việc mã hóa thông thường và MAC được trao đổi ) Những phương thức trao đổi khóa sau được hỗ trợ:

RSA: khóa bí mật được mã hóa với khóa công khai RSA của bên nhận Một public-key certificate cho khóa

bên nhận phải được tạo sẵn

Fixed Diffie-Hellman: đây là sự trao đổi khóa Diffie-Hellman trong certificate của server chứa các thông

số công khai Diffie-Hellman được ký bởi Certificate Authority (CA) Nghĩa là certificate khóa công khai chứa các thông số khóa công khai Diffie-Hellman Client chứa sẵn các thông số khóa công khai Diffie-Hellman đó trong certificate nếu chứng thực client được yêu cầu hoặc trong một message trao đổi

khóa.Phương thức này mang lại kết quả một khóa bí mật cố định giữa hai đầu, dựa trên tính toán Hellman sử dụng khóa công khai cố định

Diffie-Ephemeral Diffie-Hellman: Phương pháp được sử dụng để tạo khóa „ephemeral‟(tạm thời,1 lần)– khóa tạm

thời Trong trường hợp này, khóa công khai Diffie-Hellman được trao đổi,được ký sử dụng khóa bí mật RSA hoặc DSS của bên gửi.Bên nhận có thể sử dụng khóa công khai tương ứng để xác minh chữ ký Certificate được sử dụng để xác thực khóa công khai Điều này như là sự bảo đảm nhất của ba lựa chọn Diffie-Hellman bởi vì nó là kết quả của sự tạm thời và khóa xác thực

Anonymous Diffie-Hellman: thuật toán Diffie-Hellman cơ bản được sử dụng, không chứng thực.Nghĩa là

mỗi lần một bên gửi thông số Diffie-Hellman công khai của nó cho bên kia thì không xác thực.Điều này gần như là có thể bị tấn công bởi tấn công Man-in-the-middle ,trong đó kẻ tấn công điều khiển cả nhóm anonymous Diffie-Hellman

Fortezza: phương pháp định nghĩa cho lược đồ Fortezza

Định nghĩa kèm theo cho một phương pháp trao đổi khóa là CipherSpec , bao gồm những trường sau :

CipherAlgorithm: một vài thuật toán kể đến : RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza

MACAlgorithm: MD5 hoặc SHA-1

CipherType: luồng hoặc khối

IsExportable: True hoặc False

HashSize: 0, 16 (cho MD5), hay 20 (cho SHA-1) bytes

Key Material: thứ tự của các bytes mà chứa dữ liệu được dùng trong sinh khóa

IV Size: kích thước của giá trị khởi tạo cho mã hóa Cipher Block Chaining (CBC)

I.6.2 Giai đoạn 2 – Xác thực server và trao đổi khóa :

Server bắt đầu giai đoạn này bằng cách gửi certificate của nó nếu nó cần được xác thực; thông điệp chứa một hoặc một chuỗi certificate(chứng thực) X.509 Thông điệp chứng thực được yêu cầu cho bất kì một phương pháp trao đổi khóa nào được thỏa thuận, ngoại trừ anonymous Diffie-Hellman.Chú ý rằng nếu fixed Diffie-Hellman được dùng,thì thông điệp chứng thực có chức năng như là thông điệp trao đổi khóa của server vì nó chứa các tham số Diffie-Hellman công khai của server

Sau đó một thông điệp server_key_exchange được gửi đi nếu nó được yêu cầu.Nó không được yêu cầu trong 2 trường hợp sau:

 (1) Server đã gửi một certificate với các tham số fixed Diffie-Hellman

 (2) Trao đổi khoá RSA được dùng

Thông điệp server_key_exchange cần cho các trường hợp sau:

- Anonymous Diffie-Hellman : Nội dung thông điệp bao gồm hai giá trị Diffie-Hellman toàn cục(một số nguyên tố và một số nguyên tố cùng nhau với số đó) cùng với khóa Diffie-Hellman của server

- Ephemeral Diffie-Hellman : nội dung thông điệp bao gồm 3 tham số Diffie-Hellman cung cấp cho anonymous Diffie-Hellman,cùng với một chữ kí của các tham số này

- Trao đổi khóa RSA,mà theo đó server sử dụng RSA nhưng có một khóa chữ kí chỉ của RSA Theo đó,client không thể gửi đi cách đơn giản một khóa bí mật được mã hóa với khóa công khai/bí mật RSA phụ và sử dụng thông điệp server_key_exchanged để gửi khóa công khai.Nội dung thông điệp bao gồm hai tham số của khóa công khai RSA phụ(số mũ

và số dư) cùng với một chữ ký của các tham số này

- Fortezza: một vài chi tiết thêm về chữ kí được đảm bảo Như thường lệ,một chữ kí được tạo ra bởi việc lấy mã băm của một thông điệp và mã hóa nó với khóa bí mật của bên gửi

Trong trường hợp này mã băm được định nghĩa:

Hash (ClientHello.random||ServerHello.random||ServerParams)

Vì vậy mã băm bao gồm không chỉ các thông số Diffie-Hellman hay RSA,mà còn có hai số ngẫu nhiên từ thông điệp hello khởi tạo.Điều này đảm bảo chống lại tấn công replay và misrepresentation(giả dạng).Trong trường hợp chữ kí DSS,mã băm được biểu diễn sử dụng giải thuật SHA-1

Trong trường hợp chữ kí RSA,cả mã băm MD5 và SHA-1 đều được tính toán, và sự nối nhau của hai mã băm(36 byte) được mã hoá với khóa bí mật của server

Kế đến, một nonanonymous server(server không dùng anonymous Diffie-Hellman) có thể yêu cầu một certificate từ client.Một thông điệp certificate_request bao gồm hai thông số certificate_type và

certificate_authorities Kiểu certificate chỉ ra giải thuật khóa công khai,và nó dùng:

- RSA,chỉ dùng chữ kí

- DSS,chỉ dùng chữ kí

- RSA cho Diffie-Hellman thích hợp, trong trường hợp này chữ kí được dùng chỉ để xác thực,bằng cách gửi dùng certificate được kí với RSA

- DSS cho fixed Diffie-Hellman, một lần nữa,chỉ dùng để xác thực

- RSA cho ephemeral Diffie-Hellman

- DSS cho ephemeral Diffie-Hellman

- Fortezza

Thông số thứ 2 của thông điệp certificate_request là một danh sách các tên của những CA đặc biệt được chấp nhận Thông điệp cuối cùng trong giai đoạn 2, và là một phần luôn được yêu cầu,là thông điệp Server_done,mà được gửi cho server để chỉ ra điểm cuối của thông điệp cuối của server_hello và các message đi kèm.Sau khi gửi thông điệp,server sẽ chờ hồi đáp của client.Thông điệp này không có tham số

I.6.3 Giai đoạn 3 – Xác thực client và trao đổi khóa :

 Trong khi nhận thông điệp server_done, client sẽ xác nhận xem server cung cấp một chứng chỉ hợp lệ hay chưa nếu được yêu cầu và kiểm tra xem các thông số của server_hello được chấp nhận hay không.Nếu tất cả đều thoả mãn, client gửi một hay nhiều message trở lại cho server Nếu server yêu cầu một certificate,client bắt đầu giai đoạn này bằng cách gửi 1 thông điệp certificate.Nếu khống có certificate phù hợp nào hợp lệ, client gửi một cảnh báo

- Ephemeral hoặc Anonymous Diffie-Hellman: các tham số Diffie-hellman công khai của client được gửi đi

- Fixed Diffie-Hellman: các tham số Diffie-Hellman công khai của client được gửi đi trong một thông điệp certificate,vì vậy nội dung của thông điệp là null

- Fortezza: các tham số Fortezza của client được gửi đi

 Cuối cùng,trong giai đoạn này,client sẽ gửi 1 message certificate_verify để cung cấp xác thực tường minh của một chứng chỉ client.Thông điệp này chỉ được gửi theo sau bất kì một client certificate nào đã đánh dấu là có khả năng(nghĩa là tất cả certificate ngoại trừ những cái chứa tham số fixed Diffie-Hellman) Thông điệp này đánh dấu một mã băm dựa trên các thông điệp có trước,được định nghĩa như sau:

CertificateVerify.signature.md5_hash

MD5(master_secret || pad_2 || MD5(handshake_messages || master_secret || pad_1));

Certificate.signature.sha_hash

SHA(master_secret || pad_2 || SHA(handshake_messages || master_secret || pad_1));

 Với pad_1 và pad_2 là các giá trị được định nghĩa sớm hơn cho MAC, handshake_messages xem xét đến tất cả các thông điệp giao thức bắt tay được gửi đi hay được nhận bắt đầu từ client_hello nhưng không bao gồm thông điệp này,và master_secret là khóa bí mật được tính toán mà quá trình xây dựng sẽ được tìm hiểu sau Nếu khóa bí mật của user là DSS, thì nó được dùng để mã hóa mã băm SHA-1 Nếu khóa bí mật của user là RSA, nó được dùng để

mã hóa chuỗi mã băm MD5 và SHA-1

 Trong trường hợp khác, mục đích là để xác minh quyền sở hữu của client với khóa bí mật cho chứng thực client.Cho dù là bất cứ ai đang lạm dụng certificate của client thì cũng sẽ không thể gửi message này

I.6.4 Giai đoạn 4 – Kết thúc :

 Giai đoạn này hoàn thành thiết lập của một kết nối an toàn,Client gửi một thông điệp change_cipher_spec và chép CipherSpec đệm vào CipherSpec hiện tại.Chú ý rằng thông điệp này không được xem là một phần của giao thức bắt tay nhưng được gửi đi sử dụng giao thức Change Cipher Spec Client sau đó ngay lập tức gửi thông điệp kết thúc theo giải thuật mới, với các khóa và các bí mật.Thông điệp kết thúc xác minh xem quá trình trao đổi khóa và xác thực có thành công hay không.nội dung của thông điệp hoàn tất là một chuỗi của hai giá trị băm :

MD5(master_secret || pad2 || MD5(handshake_messages || Sender || master_secret || pad1))

SHA(master_secret || pad2 || SHA(handshake_messages || Sender || master_secret || pad1))

 Tại đó bên gửi là một mã mà xác định rằng bên gửi là client , và handshake_messages là tất cả dữ liệu từ tất cả thông điệp bắt tay trở lên nhưng không bao gồm thông điệp này

 Khi đáp lại hai thông điệp này,server gửi thông điệp change_cipher_spec của chính nó, chuyển đổi trạng thái treo cho cipherSpec hiện tại và gửi thông điệp kết thúc của nó đi.Ở điểm này quá trình bắt tay hoàn thành và client và server có thể bắt đầu trao đổi dữ liệu lớp ứng dụng

I.7 Tính toán mã hóa :

Gồm việc tạo ra 1 shared master secret bằng cách trao đổi khóa, và sự sinh ra các tham số mật mã từ master secret

I.7.1 Việc tạo Master Secret :

Shared master secret là 1 giá trị one-time 48 byte (384 bits) được sinh ra cho phiên này bằng cách trao đổi khóa an toàn.Việc tạo ra gồm hai bước:

- Đầu tiên, một pre-master-secret được trao đổi

- Thứ hai, master_secret được tính toán bằng cả hai nhóm

Đối với trao đổi pre_master_secret, có hai khả năng xảy ra:

 RSA: 48 byte pre_master_secret được sinh ra bởi client, mã hóa với khóa RSA công khai của server, và gửi cho server.Server giải mã ciphertext sử dụng khóa bí mật của nó để phục hồi lại pre_master_secret

 Diffie-Hellman: cả client và server sinh ra khóa công khai Diffie-Hellman Sau đó, những khóa này được trao đổi, mỗi bên biểu diễn việc tính toán Diffie-Hellman để tạo ra shared_pre_master_secret

Cả 2 bên tính toán master_secret như sau:

master_secret = MD5 (pre_master_secret || SHA ('A' || pre_master_secret ||ClientHello.random || ServerHello.random)) ||

MD5 (pre_master_secret || SHA ('BB' || pre_master_secret || ClientHello.random || ServerHello.random)) || MD5 (pre_master_secret || SHA ('CCC' || pre_master_secret || ClientHello.random || ServerHello.random))

Với ClientHello.random và ServerHello.random là 2 giá trị số ngẫu nhiên được trao đổi trong thông điệp hello khởi tạo ban đầu

Ị7.2 Việc sinh các tham số mã hóa :

CipherSpec yêu cầu một khóa xác thực của client, một khóa xác thực của server, và một khóa mật mã của client, một khóa mật mã của server, một vector khởi tạo IV của client, một vector khởi tạo IV của server, mà được sinh ra

từ master_secret theo thứ tự đó.Những tham số này được sinh ra từ master_secret bằng cách băm master_secret thành chuỗi liên tục các byte bảo mật với chiều dài vừa đủ của những tất cả các tham số cần thiết

Việc sinh nguyên liệu khóa từ master_secret sử dụng cùng định dạng cho việc sinh ra master_secret từ

pre_master_secret:

key_block = MD5(master_secret || SHẮÁ || master_secret || ServerHellọrandom || ClientHellọrandom)) || MD5(master_secret || SHẮBB' || master_secret || ServerHellọrandom || ClientHellọrandom)) ||

MD5(master_secret || SHẮCCC' || master_secret || ServerHellọrandom || ClientHellọrandom)) ||

Cho đến khi đủ số output được phát sinh.Kết quả của cấu trúc giải thuật này là hàm sinh số ngẫu nhiên

Ta có thể xem master_secret như giá trị ngẫu nhiên đưa hạt giống sinh số ngẫu nhiên vào trong hàm sinh số ngẫu nhiên.Các số ngẫu nhiên client và server có thể được nhìn như là các giá trị không đáng tin cậy(salt value) làm phức

tạp sự giải mã các mật mã

I.8 Transport Layer Security :

I.8.1 Version Number :

Định dạng của một record TLS giống định dạng của record SSL, và các trường trong phần header cũng có ý nghĩa giống nhau.Một sự khác biệt là trong các giá trị phiên bản TLS hiện tại,bản chính là 3 và bản phụ là 1

I.8.2 Message Authentication Code :

Có 2 điểm khác biệt giữa SSLv3 và TLS MAC schemes: giải thuật thực tế và phạm vi của phép tính MAC

TLS tạo ra việc sử dụng giải thuật HMAC được định nghĩa trong RFC 2104.Nhớ lại,HMAC được định nghĩa như sau:

HMACK(M) = H[(K+ opad)||H[(K+ ipad)||M]]

Với : H: hàm băm nhúng(dành cho TLS, hoặc MD5 hoặc SHA-1)

M: thông điệp đầu ra đối với HMAC

K+ : khóa bí mật đệm các số 0 vào phía bên trái để kết quả bằng với chiều dài khối mã băm (đối với MD5, và SHA-1, chiều dài khối bằng 512 bits)

Ipad =00110110(36H) lặp lại 64 lần (512 bits) Opad =01011100(5CH) lặp lại 64 lần (512 bits) SSLv3 dùng cùng giải thuật, ngoại trừ các byte đệm được nối vào vào khóa bí mật hơn là được XOR với khóa bí mật được đệm vào chiều dài khối.Mức độ an toàn cùng giống trong cả 2 trường hợp

Đối với TLS, phép tính toán MAC hoàn thành các trường hợp được chỉ ra trong đẳng thức sau:

HMAC_hash(MAC_write_secret, seq_num || TLSCompressed.type || TLSCompressed.version ||

TLSCompressed.length || TLSCompressed.fragment)

Phép toán MAC bao gồm tất cả các trường được hàm chứa bởi phép tính toán SSLv3, cộng với trường

TLSCompresses.version, mà là version của giao thức đang được dùng

I.8.3 Hàm tính số nhẫu nhiên :

TLS tạo cách sử dụng hàm tạo số ngẫu nhiên dùng cho PRF để mở rộng các secret(phần bí mật) thành các khối dữ liệu cho mục đích sinh khóa hay phê chuẩn.Đối tượng là để tạo ra cách sử dụng các giá trị shared secret nhỏ có liên

hệ với nhau, nhưng để phát sinh các khối dài hơn theo cách an toàn khỏi sự tấn công dựa trên hàm băm và

MACx.PRF dựa trên hàm mở rộng dữ liệu sau:

P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) ||

HMAC_hash(secret, A(2) || seed) ||

HMAC_hash(secret, A(3) || seed) ||

Với A() được định nghĩa:

A(0)=seed A(i) =HMAC_hash(secret,A(i-1))

Hàm mở rộng dữ liệu tạo cách sử dụng giải thuật HMAC, với hoặc MD5 hoặc SHA-1 như là trên cơ sở hàm

băm.Như ta có thể thấy,P_hash có thể lặp đi lặp lại nhiều lần như sự cần thiết để tạo ra số lượng dữ liệu được yêu cầu.Ví dụ, nếu P_SHA-1 được dùng để sinh ra 64 byte dữ liệu,nó sẽ được lặp đi lặp lại 4 lần tạo ra 80 byte dữ liệu,mà 16 byte cuối bị loại bỏ.Trong trường hợp này,P_MD5 cũng sẽ được lặp lại 4 lần,tạo ra chính xác 64 bytes

dữ liệu.Chú ý rằng mỗi lần lặp lại sẽ gọi 2 hàm thực thi HMAC, mỗi một cái sẽ quay sang gọi 2 hàm thực thi trên cơ

sở giải thuật hàm băm

Để tạo ra PRF an toàn đến mức có thể,nó sử dụng 2 giải thuật băm theo cách mà sẽ đảm bảo sự an toàn của nó nếu giải thuật vẫn còn bảo mật.PRF được định nghĩa :

hash(ClientHello.random || ServerHello.random || ServerParams)

PRF lấy khi đầu vào một giá trị bí mật, một nhãn xác định, và một giá trị hạt giống(seed) và tạo ra một output có chiều dài tùy ý.Output được tạo bằng cách phân cắt giá trị bí mật thành hai nửa (S1 và S2 và biểu diễn P_hash ở mỗi nửa,sử dụng MD5 ở một nửa và SHA-1 ở nửa khác.Hai kết quả được thực hiện bởi phép XOR để tạo ra output, cho mục đích này,P_MD5 nhìn chung phải lặp lại nhiều lần hơn P_SHA-1 để tạo một lượng dữ liệu ngang bằng cho input bằng hàm XOR)

I.8.4 Mã cảnh báo :

TLS hỗ trợ tất cả các mã alert code được định nghĩa trong SSLv3 với ngoại lệ no_certificate Một số các code thêm vào được định nghĩa trong TLS, sau đây là một số cảnh báo mức nguy hiểm:

 decryption_failed : một cipher text được giải mã theo cách sai, hoặc nó không phải là phép nhân của chiều dài

khối hoặc giá trị đệm của nó,khi kiểm tra là không đúng

 record_overflow:một TLS record được nhận với một payload(ciphertext) có chiều dài 214+2048 bytes, hoặc ciphertext được giải mã với chiều dài lớn hơn 214

+1024 byte

 unknown_ca : một chuỗi certificate hợp lệ hoặc 1 phần chuỗi được nhận,nhưng certificate không được chấp

nhận bởi vì CA certificate không thể được cấp phát hoặc không thể tạo ra kết nối với 1 CA hiểu biết,tin cậy

 access_defined: một certificate hợp lệ được nhận, vì khi access_control được thừa nhận, sender quyết định

không thực thi với thỏa thuận

 decord_error : một thông điệp không thể được giải mã vì 1 trường bị thiếu range đặc biệt hoặc chiều dài của

message không đúng

 export_restriction : một thỏa thuận không được chấp nhận với việc xuất ra các hạn chế trên chiều dài khóa bị

phát hiện

 protocol_version: phiên bản giao thức mà client nỗ lực thỏa thuận được nhận thấy nhưng không hỗ trợ

 insufficient_security: trả về thay thế handshake_failure khi thỏa thuận bị thất bại 1 cách đặc biệt bởi vì server

yêu cầu cipher nhiều bảo mật hơn những cái khác được hỗ trợ bởi client

 internal_error: một lỗi bên trong không liên hệ với cấp tương đương hoặc sự sửa lỗi của giao thức tạo ra

không thể để tiếp tục

Phần còn lại của các cảnh báo mới bao gồm:

 decrypt_error: toán hạng mã hóa bắt tay bị hư, bao gồm không thể xác minh 1 chữ kí,mã hóa 1 trao đổi khóa

hay công nhận 1 thông điệp hoàn tất

 user_canceled: quá trình bắt tay này bị hoãn lại vì 1 số lí do không liên quan đến sự thất bại giao thức

 no_renegotiation: gửi đi bởi client trong phần đáp lại client hello sau khi thiết lập bắt tay.hoặc những thông

điệp này sẽ có kết quả bình thường trong việc thỏa thuận lại,nhưng cảnh báo này chỉ ra rằng sender không thể thỏa thuận.Thông điệp này luôn luôn là 1 cảnh báo(warning)

I.8.5 Cipher suite :

Có nhiều sự khác nhau nhỏ giữa các cipher suite sẵn có dưới SSLv3 và dưới TLS:

 Trao đổi khóa:TLS hỗ trợ tất cả các công nghệ trao đổi khóa của SSLv3 với ngoại lệ của Fortezza

 Các giải thuật mã hóa đối xứng:TLS bao gồm tất cả các giải thuật mã hóa đối xứng được tìm thấy trong SSLv3,với ngoại lệ của Fortezza

I.8.6 Các dạng client certificate :

TLS định nghĩa cá kiểu certificate sau đây được yêu cầu trong thông điệp

certificate_request:rsa_sign,dss_sign,rsa_fixed_dh, và dss_fixed_dh Tất cả những kiểu này được định nghĩa trong SSLv3 Thêm vào đó,SSLv3 bao gồm rsa_ephemeral_dh, dss_ephemeral_dh và fortezza_kea

Ephemeral Diffie-Hellman bao gồm đánh dấu các tham số Difie-Hellman với hoặc RSA hoặc DSS, với TLS, rsa_sign và kiểu đánh dấu riêng không cần thiết để đánh dấu các tham số Diffie-Hellman.TLS không bao gồm hê thống Fortezza

I.8.7 Certificate Verify và Finished Message :

Trong thông điệp TLS_certificate_verify, mã băm MD5 và SHA-1 được tính toán chỉ trên các thông điệp bắt tay(handshake_message).Nhớ lại rằng SSLv3 tính toán hàm băm còn bao gồm master_secret và đệm.Các trường thêm vô này thất bại trong việc cộng thêm bảo mật không được thêm vào

Khi các thông điệp hoàn tất trong SSLv3, thông điệp kết thúc trong TLS là 1 mã băm dựa trên

shared_master_secret, thông điệp bắt tay ở trước, và một nhãn xác định client hay server, việc tính toán có đôi chút khác biệt

Đối với TLS ta có:

PRF(master_secret, finished_label, MD5(handshake_messages)|| SHA-1(handshake_messages))

Với finished_label là chuỗi “client_finished” đối với client và “server finished” đối với server

I.8.8 Tính toán mã hóa :

Pre_master_secret đối với TLS được tính toán cùng 1 cách như trong SSLv3.Như trong SSLv3, master_secret trong TLS được tính toán như 1 hàm băm của pre_master_secret và hai số ngẫu nhiên hello.Công thức của phép tính toán TLS khác với công thức tính của SSLv3,được định nghĩa như sau:

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random || ServerHello.random)

Giải thuật biểu diễn cho đến khi 48 byte của output số ngẫu nhiên được tạo ra.Phép tính toán của khối vật liệu key(MAC secret keys,khóa mã hóa phiên, và ma trận khởi tạo IVs) được định nghĩa như sau:

key_block = PRF(master_secret,"key expansion",SecurityParameters.server_random ||

Chương II :

II.1 Quan hệ giữa các Class :

Để liên lạc một cách bảo mật, cả hai đầu của kết nối phải kích hoạt SSL Trong JSSE API, những lớp đầu cuối của kết nối là SSLSocket và SSLEngine Trong biểu đồ bên dưới, những class lớn được dùng để tạo

SSLSocket/SSLEngines được sắp xếp theo trật tự logic

Một SSLSocket thì được tạo bởi một SSLSocketFactory hoặc một SSLServerSocket cho việc nhận vào một kết nối inbound.( mặt khác, một SSLServerSocket được tạo bởi một SSLServerSocketFactory) Cả các đối tượng SSLSocketFactory và SSLServerSocketFactory được tạo bởi SSLContext Một SSLEngine được tạo một cách trực tiếp bởi SSLContext, và dựa vào ứng dụng để quản lý tất cả I/O

Ghi chú: Khi sử dụng SSLSockets/SSLEngines ta nên kiểm tra xác thực đầu cuối trước khi gửi dữ liệu Lớp

SSLSocket/SSLEngine sẽ không tự động xác minh, ví dụ hostname trong một URL trùng với hostname trong xác thực đầu cuối Ứng dụng có thể bị lợi dụng URL spoofing nếu hostname không được xác minh

Có hai cách để sử dụng và khởi tạo một SSLContext:

Đơn giản nhất là gọi phương thức tĩnh getDefault trên lớp SSLSocketFactory hoặc

SSLServerSocketFactory Những phương thức này tạo một SSLContext mặc định với một KeyManager, TrustManager và một bộ khởi tạo số bí mật ngẫu nhiên (Một

KeyManagerFactory và TrustManagerFactory mặc định được sử dụng để tạo KeyManager và TrustManager tương ứng.) Key material được tìm thấy trong keystore/truststore mặc định, được định rõ bởi tính chất hệ thống mô tả trong Customizing the Default Key and Trust Stores, Store Types, and Store Passwords

Phương thức trao đổi bên gọi phần lớn điều khiển cách hoạt động của context được tạo thì gọi là phương thức tĩnh getInstance trên lớp SSLContext , sau đó khởi tạo context bằng cách gọi phương thức riêng init của trường hợp Một thực thể của phương thức init mang ba phần sau: một dãy đối tượng KeyManager, một dãy đối tượng TrustManager và một bộ sinh số bí mật ngẫu nhiên

SecureRandom Đối tượng KeyManager và TrustManager được tạo bởi việc bổ sung các

interface(s) thích hợp hoặc dùng lớp KeyManagerFactory và TrustManagerFactory để phát sinh các bổ sung KeyManagerFactory và TrustManagerFactory có thể được khởi tạo với mỗi key material chứa trong KeyStore qua phương thức TrustManagerFactory/KeyManagerFactory init Cuối cùng phương thức getTrustManagers (trong TrustManagerFactory) và phương thức getKeyManagers (trong KeyManagerFactory) có thể được gọi để sử dụng những chuỗi của trust hoặc key managers,một cho mỗi loại của trust hoặc key material

Mỗi một kết nối SSL được khởi tạo thì một SSLSession được tạo chứa các thông tin đa dạng, như là ID khởi tạo, bộ mã hóa được dùng , v.v SSLSession khi đó được dùng thể hiện mối liên hệ xảy ra bên trên và thông tin trạng thái giữa hai thực thể Mỗi kết nối SSL bao gồm 1 phiên tại một thời điểm nhưng phiên đó thì lại có thể được dùng bởi nhiều kết nối giữa những thực thể đó,đồng thời hoặc theo thứ tự

II.2 Các Class và Interface chính :

II.2.1 Lớp SocketFactory và ServerSocketFactory :

Lớp trừu tượng javax.net.SocketFactory được dùng để tạo socket Nó phải là subclassed của các factories khác, mà tạo những subclasses riêng biệt của sockets và vì vậy cung cấp một framework tổng quát cho phần thêm vào của chức năng public socket-level (xem ví dụ SSLSocketFatory )

Lớp javax.net.ServerSocketFactory thì tương tự lớp SocketFactory, nhưng nó chỉ dành riêng cho việc tạo server sockets

Socket factories là cách đơn giản để các chính sách liên quan đến sockets được xây dựng,việc thiết lập sockets theo một cách nào đó thì không yêu cầu cấu hình riêng biệt cho code mà đòi hỏi:

Vì sự đa hình của factories và sockets, những dạng khác nhau của sockets có thể cùng dùng code ứng dụng

mà bỏ qua các dạng khác nhau của factories

Factories có thể tự tùy chỉnh thông số với các thông số sử dụng trong xây dựng socket Ví dụ factories tự điều chỉnh để trả về sockets với những timeouts mạng khác nhau hoặc thông số security đã cấu hình

Sockets trả về ứng dụng subclasses của java.net.Socket (hay javax.net.ssl.SSLSocket), cho nên ta có thể trình bày một APIs mới cho những đặc trưng như nén , bảo mật ,đánh dấu record,lựa chọn thống

kê, hay vượt tường lữa

II2.2 Lớp SSLSocketFactory và SSLServerSocketFactory :

Một javax.net.ssl.SSLSocketFactory hoạt động như một factory cho việc tạo secure sockets Lớp này

là một phân lớp trừu tượng của javax.net.SocketFatory

Secure socket factories đóng gói chi tiết của việc tạo và cấu hình ban đầu secure sockets Bao gồm xác thực keys, công nhận certificate đầu bên kia, kích hoạt bộ mã hóa và tương tự

Lớp javax.net.ssl.SSLServerSocketFactory thì tương tự lớp SSLSocketFactory, nhưng được sử dụng riêng cho việc tạo server sockets

Tạo một SSLSocketFactory :

Có ba cách cơ bản để tạo SSLSocketFactory:

Lấy factory mặc định bằng việc gọi phương thức tĩnh SSLSocketFactory.getDefault

Nhận một factory như là 1 thông số API Đó là code cần tạo sockets nhưng không quan tâm chi tiết như thế nào sockets được cấu hình có thể bao gồm 1 phương thức với 1 thông số SSLSocketFactory được gọi bởi clients để chỉ rõ SSLSocketFactory dùng để tạo sockets,vd : javax.net.ssl.HttpsURLConnection Xây dựng một factory mới với cách chạy được cấu hình riêng biệt

Factory mặc định được cấu hình đặc trưng để hổ trợ chứng thực server chỉ khi sockets được tạo bởi một factory mặc định không rò rĩ bất cứ thông tin nào về về client hơn một TCP socket bình thường làm

Nhiều lớp tạo và dùng sockets thì không cần biết chi tiết của cách tạo sockets.Việc tạo sockets qua một sockets factory được lướt qua như một thông số như là một cách tốt để cách ly chi tiết của cấu hình socket và tăng sự tái dụng của lớp mà tạo và dùng sockets

Bạn có thể tạo một socket factory mới bằng việc triển khai socket factory subclass của bạn hay sử dụng lớp khác mà hoạt động như một factory cho socket factories Một ví dụ là lớp SSLContext mà được cung cấp trong JSSE như là một lớp cung cấp cấu hình cơ sở

II.2.3 Lớp SSLSocket và SSLServerSocket :

Lớp javax.net.ssl.SSLSocket là một subclass của lớp chuẩn java.net.Socket Nó hỗ trợ tất cả phương thức socket chuẩn và thêm những phương thức bổ sung đặc trưng vào secure sockets Cá biệt của lớp này là đóng gói SSLContext bên dưới những gì mà nó tạo Có những APIs điều khiển việc tạo secure socket sessions cho một socket riêng biệt nhưng việc quản lý trust và key không được che đậy một cách trực tiếp

Lớp javax.net.ssl.SSLServerSocket thì tương tự lớp SSLSocket ,nhưng được dùng đặc trưng cho cho việc tạo server sockets

Để ngăn spoofing đầu bên,bạn nên luôn xác minh đầu cuối cho một SSLSocket

Ghi chú bổ sung : do sự phức tạp của giao thức SSL và TLS ,nó khó để dự đoán có hay không bytes vào trên một kết nối là handshake hay dữ liệu ứng dụng,và như thế nào dữ liệu có thể tác động trạng thái kết nối hiện tại (ngoại trừ trường hợp quá trình bị block) Trong thực thi của Sun JSSE, phương thức available()trên đối tượng đạt được từ SSLSocket.getInputStream()trả về tổng số của bytes dữ liệu ứng dụng giải mã thành công từ kết nối kết nối SSL nhưng lúc này chưa đọc bởi ứng dụng

Tạo một SSLSocket :

SSLSocket có thể tạo được bằng hai cách Thứ nhất, một SSLSocket có thể tạo bởi SSLSocketFactory qua một vài phương thức createSocket trên lớp đó Cách thứ hai tạo SSLSockets qua phương thức accept trên lớp SSLServerSocket

II.2.4 Non-blocking I/O với SSLEngine :

SSL/TLS đang ngày càng phổ biến Nó được dùng trong các ứng dụng đa dạng trên một diện rộng các nền máy tính Theo đà sự phổ biến hiện nay dẫn đến yêu cầu sử dụng nó với những I/O và mô hình chuỗi khác nhau để mà thỏa mãn hiệu suất , khả năng , theo dõi và những yêu cầu khác của ứng dụng.Đó là sự đòi hỏi sử dụng nó trong trong những kênh I/O blocking và non-blocking , I/O không đồng bộ, các luồng input và output đa dạng , và những bộ đệm byte.Đó là sự yêu cầu nó trong môi trường nhạy cảm có độ biến đổi và hiệu suất cao mà yêu cầu quản lý hàng ngàn network connections

Trước J2SE 5 , JSSE API hổ trợ chỉ một khái niệm trừu tượng transport đơn : luồng sockets nền thông qua

SSLSocket Trong khi dạng này tương thích với nhiều ứng dụng , nó không gặp phải những yêu cầu của ứng dụng

mà cần dùng I/O khác nhau hay mô hình liên kết Trong 1.5.0 , một khái niệm trừu tượng mới được giới thiệu để cho phép ứng dụng sử dụng giao thức SSL/TLS trong một đường vận chuyển độc lập , vì vậy những ứng dụng tự

do chọn cách thức vận chuyển và mô hình tính toán tốt nhất mà nó cần Nó còn thích nghi với nhiều mô hình liên kết Điếu này cho phép một cách hiệu quả I/O và liên kết vào ứng dụng Bởi vì tính linh hoạt này , ứng dụng bây giờ phải quản lý I/O và liên kết ( những topic phức tạp vào trong chính nó) cũng như nắm rõ giao thức SSL/TLS Một khái niệm trừu tượng mới cho ra một API cao cấp : người dùng nên sử dụng SSLSocket

Một người mới tiếp xúc API có thể tự hỏi “ Tại sao không chỉ có một SSLSocketChannel mà thuộc

java.nio.channels.SocketChannel?" Có hai lý do chính sau :

Có nhiều câu hỏi khó về một SSLSocketChannel thì nên như thế nào gồm cả hệ thống phân lớp của

nó và nó nên liên kết với Selectors và những dạng khác của SocketChannels như thế nào.Mỗi đề xuất thì mang lại nhiều câu hỏi hơn là trả lời Nó được giải thích rằng khái niệm trừu thượng API mới mở rộng để làm việc với SSL/TLS yêu cầu cùng một các phép phân tích quan trọng và có thể dẫn đến những APIs lớn và phức tạp

Bất kỳ việc thực thi JSSE nào cho một API mới sẽ tự do chọn lựa I/O và chiến lược tính toán tốt nhất , nhưng ẩn đi những chi tiết không thích hợp cho yêu cầu điều khiển ứng dụng đó Bất kỳ sự thực thi đặc trưng nên tách rời với các phân đoạn ứng dụng

Bằng việc trừu tượng I/O và dữ liệu xữ lý như những chuỗi bytes, kết quả được giải quyết và API mới có thể sử dụng với bất cứ mô hình I/O nào hiện nay và sắp tới.Trong khi giải pháp này làm I/O và CPU chuyển giao trách nhiệm cho người lập trình , việc thực thi JSSE thì bị ngăn không cho trở nên không sử dụng được bởi vì những chi tiết bên trong không thể cấu hình hay thay đổi

Người dùng những API ngôn ngữ lập trình lập trình Java khác như JGSS và SASL sẽ thông báo những điều tương

tự rằng ứng dụng thì cũng chịu trách nhiệm cho dữ liệu vận chuyển

SSLEngine

Lớp chính trong khái niệm mới này là javax.net.ssl.SSLEngine Nó đóng gói một SSL/TLS cơ chế trạng thái và cách vận hành trên bộ đệm byte inbound và outbound hổ trợ bởi người dùng của SSLEngine Lược đồ sau sẽ minh họa luồng dữ liệu của data từ ứng dụng , đến SSLEngine , đến cơ chế vận chuyển và quay về

Tầng ứng dụng ở bên trái cung cấp dữ liệu ứng dụng (plaintext) trong một application buffer và chuyển nó cho SSLEngine SSLEngine xử lý dữ liệu chứa trong buffer hoặc bất cứ dữ liệu handshaking nào để tạo ra dữ liệu đã

mã hóa SSL/TLS vào đặt vào network buffer cung cấp bởi ứng dụng Ứng dụng thì sau đó chịu trách nhiệm cho việc vận chuyển tương ứng (bên phải) để gửi nội dung của network buffer đến đầu bên.Lúc nhận dữ liệu đã mã hóa SSL/TLS từ đầu bên ( thông qua tầng vận chuyển) , ứng dụng đưa dữ liệu vào trong network buffer và chuyển nó đến SSLEngine SSLEngine xử lý nội dung network buffer để tạo ra dữ liệu handshaking hay dữ liệu ứng dụng

Về tổng thể , SSLEngine có thể là một trong năm trạng thái :

1 Creation – sẵn sàng để cấu hình

2 Initial handshaking - thực thi chứng thực và thương lượng thông số truyền thông

3 Application data – sẵn sàng cho trao đổi dữ liệu

4 Rehandshaking - tái thương lượng thông số truyền thông / chứng thực;dữ liệu handshaking có thể đã được gắn vào dữ liệu ứng dụng

5 Closure – sẵn sàng đóng kết nối

Năm trạng thái này được miêu tả chi tiết hơn trong tài liệu lớp SSLEngine

II.2.5 Quá trình khởi động :

Để tạo một SSLEngine , bạn sử dụng phương thức SSLContext.createSSLEngine() Bạn phải cấu hình cơ chế hoạt động như một client hoặc một server, cũng như đặt các thông số cấu hình khác như là cipher suites được dùng và có yêu cầu chứng thực client không

Đây là một ví dụ mà tạo một SSLEngine Chú ý rằng tên server và số port thì không được dùng cho liên lạc với server – tất các vận chuyển là trách nhiệm của ứng dụng.Chúng gợi ý cho người cung cấp JSSE sử dụng việc cache SSL session, và cho việc thực thi Kerberos-cipher suite cơ bản để định rõ ủy quyền server nào nên được chọn import javax.net.ssl.*;

import java.security.*;

// Khởi tạo SSLContext với key material

char[] passphrase = "passphrase".toCharArray();

// Khởi tạo lần đầu key và trust material

KeyStore ksKeys = KeyStore.getInstance("JKS");