Đề tài bảo mật thông tin EXTENSIBLE AUTHENTICATION PROTOCOL TRANSPORT LAYER SECURITY(EAP TLS)

Trang 1

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP HCM

ĐỀ TÀI BẢO MẬT THÔNG TIN

EXTENSIBLE AUTHENTICATION PROTOCOL

TRANSPORT LAYER SECURITY

(EAP-TLS)

Giảng viên hướng dẫn: Th.S Văn Thiên Hoàng

Nhóm Sinh viên thực hiện:

Mã Chí Trung Mssv: 1191020168 Lớp: 11HTHM1 Phạm Minh Trung

Mssv: 1191020164 Lớp: 11HTHM1 Phạm Gia Đông

Mssv: 1191020017 Lớp: 11HTHM1 Trịnh Hưng Hưng

Mssv: 1191020039 Lớp: 11HTHM1

Võ Thanh Tâm Mssv: 1191020120 Lớp: 11HTHM1 Trịnh Đăng Tuấn

Mssv: 1191020175 Lớp: 11HTHM1

TP Hồ Chí Minh, 2012

Trang 2

CHƯƠNG I: GIỚI THIỆU TỔNG QUAN EAP-TLS

1.1 EAP-TLS là gì ?

EAP-TLS là chữ viết tắt của Extensible Authentication Protocol – Transport Layer Security

(giao thức thẩm định quyền truy cập có thể mở rộng – bảo mật lớp truyền dẫn) Kết nối dựatrên giao thức này đòi hỏi có một chứng nhận người sử dụng (user certificate) trên cả máykhách và máy chủ IAS

Đây là cơ chế có mức độ an toàn nhất ở cấp độ người sử dụng, nó cho phép một phươngpháp xác thực tùy ý được sử dụng để truyền thông tin ủy nhiệm và trao đổi thông tin cóchiều dài tùy ý

EAP là một phần mở rộng cho Point-to-point (PPP) và giao thức này được tổ chức IETF

định nghĩa trong cuốn RFC 2284

Các đặc tính của EAP-TLS bao gồm:

 Xác thực lẫn nhau (giữa máy chủ và khách hàng)

 Trao đổi khoá (để thiết lập WEP động và khoá TKIP)

 Phân mảnh và nối lại (với bản tin EAP dài cần có phần kích thước kiểm tra nếu cần)

 Kết nối nhanh (thông qua TLS)

1.1.1 Nhu cầu sử dụng

EAP được tạo nhằm phản hồi lại yêu cầu về những phương pháp xác thực mạnh mẽ hơn,

những phương pháp này sao lưu dự phòng những thiết bị bảo mật bổ sung, chẳng hạn nhưcác chứng nhận hoặc smart card cũng như các tổ hợp tên người dùng và password chuẩn

Hiện nay EAP là phương pháp theo tiêu chuẩn công nghiệp để sử dụng với những

phương pháp xác thực bổ sung với PPP

EAP-TLS sử dụng khoá kiểm tra công khai TLS trong EAP để cung cấp việc xác thực lẫn

nhau giữa máy chủ và khách hàng Với EAP-TLS, cả máy chủ và khách hàng đều phải

đăng ký chữ ký dạng số thông qua quyền chứng thực (CA) để kiểm tra

EAP cung cấp bảo mật mạnh mẽ bằng cách yêu cầu cả máy chủ lẫn máy khách xác nhận

chứng thực bằng PKI.Các gói tin EAP tương tác với máy khách lẫn máy chủ được mã hóa và bảo vệ kết nối mạng bằng TLS Nhược điểm với giao thức này là sử dụng và cài

đặt chứng thực luôn ở cả hai bên

Trang 3

1.1.2 Giải pháp công nghệ liên quan

Ngày nay các mạng 802.11 xác thực theo chuẩn 802.1x Chuẩn này xác định giao thức

xác thực mở rộng (EAP) trực tiếp qua lớp kết nối EAP là giao thức truyền thông được sử

dụng thông qua các loại cơ chế xác thực khác nhau Các phương pháp EAP phát triển chomạng không dây được dựa trên việc kiểm tra thông qua khoá công cộng và giao thức bảo

mật tại lớp truyền dẫn (TLS) Các giao thức đó là EAP-TLS, EAP-TTLS và PEAP

 EAP-TTLS :

Giao thức chứng thực đường hầm (EAP-TTLS) cung cấp một loạt các thuộc tính cho một bản tin như RADIUS EAP - dùng tầng vận chuyển, EAP-TTLS có thể

cung cấp các chức năng như phương thức PEAP Tuy nhiên nếu mật khẩu của

RADIUS hoặc CHAP được mã hoá, thì TTLS có thể bảo vệ được các tính chất kế thừa của RADIUS Khi máy chủ TTLS gửi bản tin RADIUS tới máy chủ tại đích,

nó sẽ giải mã các thuộc tính bảo vệ của EAP-TTLS và chèn chúng trực tiếp vào bản tin chuyển đi Bởi vì phương thức này giống như PEAP, nên nó ít được sử

dụng hơn

Hình 1- Giao diện TTLS

 PEAP :

Giống như chuẩn TTLS, PEAP tạo khả năng xác thực cho mạng LAN không dây

mà không yêu cầu xác thực Protected EAP ( PEAP ) thêm lớp TLS lên trên cùng

EAP giống như EAP-TTLS, rồi sau đó sử dụng kết quả của phiên TLS như

phương tiện vận chuyển để bảo vệ phương thức EAP PEAP sử dụng TLS để xác

thực từ máy chủ tới máy trạm nhưng không có chiều ngược lại Theo phương thứcnày chỉ máy chủ yêu cầu khoá xác thực còn khách hàng thì không Máy chủ và

máy trạm trao đổi chuỗi thông tin mã hoá trong TLS, và bản tin TLS được xác

thực và mã hoá sử dụng khoá đã được thông qua giữa hai bên

Trang 4

PEAP cung cấp dịch vụ cho phương thức EAP như sau:

 Bản tin xác nhận (Những kẻ tấn công sẽ rất khó khăn trong việc chèn vào bảntin EAP)

 Mã hoá bản tin (Những kẻ tấn công sẽ không thể đọc và giải mã bản tin EAP)

 Xác thực từ máy chủ đến khách hàng (vì thế phương thức này chỉ cần bảo vệxác thực từ khách hàng tới máy chủ)

 Trao đổi khoá (để thiết lập cho WEP động hoặc khoá TKIP)

 Phân mảnh và ghép lại (cần thiết nếu bản tin EAP dài)

 Thiết lập kết nối nhanh ( thông qua phiên TLS )

1.1.3 Môi trường áp dụng

EAP-TLS thường được sử dụng trong các mô trường doanh nghiệp lớn, tuy nhiên cũng

có thể được sử dụng trong các tổ chức nhỏ hơn

802.1x là chuẩn đặc tả cho việc truy cập dựa trên cổng (port-based) được định nghĩa bởiIEEE Hoạt động trên cả môi trường có dây truyền thống và không dây Việc điều khiểntruy cập được thực hiện bằng cách: khi một người dùng cố gắng kết nối vào hệ thốngmạng, kết nối của người dùng sẽ được đặt ở trạng thái bị chặn ( blocking ) và chờ choviệc kiểm tra định danh người dùng hoàn tất

Mô hình xác thực 802.1X-EAP cho Client diễn ra như sau:

Trang 5

Hình 2- Quá trình trao đổi thông tin xác thực của 802.1x

Trang 6

1.1.4 Phân loại EAP Packet

5 One-Time Password (OTP)

6 Generic Token Card (GTC)

Trang 7

12 KEA-VALIDATE

14 Defender Token (AXENT)

15 RSA Security SecurID EAP

17 EAP-Cisco Wireless (LEAP)

18 Nokia IP SmartCard authentication

22 Remote Access Service

23 UMTS Authentication and Key Agreement

Trang 9

44-191 Not assigned; can be assigned by IANA on the

advice of a designated expert

192–253 Reserved; requires standards action

1.2 Mô hình kiến trúc và triển khai ứng dụng

802.1x EAP-TLS được sử dụng trong các mô trường cơ bản và an toàn cao Sự trao đổi của các message EAP-TLS cung cấp sự xác nhận lẫn nhau, sự bắt tay của giao thức mã hóa và sự trao đổi khóa bảo vệ giữa một client không dây và mạng EAP-TLS là một kỹ

thuật cung cấp các khóa mã hóa động cho người dùng và session Điều này cải thiện một

Trang 10

cách đáng kể và vượt qua nhiều điểm yếu trong các mạng không dây Hình dưới đây chỉ

ra một chuỗi các sự kiện xuất hiện khi một Client được xác nhận bằng 802.1x EAP-TLS.

Hai chứng chỉ digital được yêu cầu ở đây: một trên RADIUS server (ví dụ EAS) và mộttrên Client không dây Chú ý rằng sự truy cập không dây được cung cấp cho tới khi sựxác nhận thành công và các khóa WEP động đã được thiết lập

Hình 3-Xác nhận 802.1x EAP-TLS

802.1x EAP-TLS với EAS trong Controller Mode Client không dây có chứng chỉ điện tử

(digital certificate) được cài đặt từ trước Mạng nội bộ không dây (WLAN) giao tiếp vớiEAS thông qua Access Point (AP) Tất cả ba thành phần (Wireless client, AP và EAS) hỗ

trợ cho quá trình chứng thực 802.1x EAP-TLS.WLAN có thể sử dụng Windows XP (được xây dựng để hỗ trợ cho 802.1x EAP-TLS hay Windows 98/Me/2000) bằng việc sử dụng

Madge Wireless LAN Utility (WLU) Khi xác nhận, dữ liệu người dùng cũng có thể được

sử dụng EAS mà đã được cấu hình trong Gateway Mode

Trang 11

Hình 4- 802.1x EAP-TLStrong Controller Mode

CHƯƠNG II: GIAO THỨC EXTENSIBLE AUTHENTICATION

PROTOCOL – TRANSPORT LAYER SECURITY

2.1 Giao thức EAP-TLS:

2.1.1 Sơ đồ hoạt động của EAP-TLS (RFC 5216)

Trang 12

Được mô tả trong RFC 5216, cuộc đối thoại sẽ được bắt đầu với bên gửi và bên nhận tiếnhành thương lượng các gói tin EAP.Bên server sẽ gửi một gói tin EAP-Request cho clientyêu cầu xác định danh tính ( Indentify ), sau đó client sẽ phản hồi ngược lại cho server bằnggói tin EAP-Response chứa User-ID của mình.Kể từ đó cuộc nói chuyện sẽ được bắt đầugiữa EAP-Server và client.

Một khi đã nhận được Identity của client, EAP-Server phải phản hồi cho client bằng gói tinEAP-TLS start, đó là một gói EAP-Request với EAP-type=EAP-TLS, cuộc trò chuyện bắtđầu, bên phía client sẽ gửi một gói tin EAP-Response, type=EAP-TLS.Trường dữ liệu của

Trang 13

gói tin sẽ được đóng gói một hoặc nhiều TLS record ở định dạng TLS record layer, chứathông điệp bắt tay ( TLS client_hello ).

Client_hello message bao gồm số phiên bản TLS của client ( peer’s TLS version number ),session ID, một con số phát sinh ngẫu nhiên và bộ mã hoá được hỗ trợ bởi client.Phiên bảnTLS của client phải tương ứng với TLS v1.0 hoặc cao hơn

EAP-Server sẽ trả lời lại với một gói tin EAP-Request với EAP-type=EAP-TLS, gói tin này bao gồm TLS server_hello handshake message, server_key_exchange,

certificate_request,server_hello_done.Trong đó server_hello_handshake message gồm TLS version number , một con số phát sinh ngẫu nhiên khác ( another random number ), session

ID và một bộ mã hoá ( ciphersuite )

Nếu session ID của client là null hoặc server không thể nhận biết được thì lúc này server sẽphải chọn một session ID khác để thiết lập phiên giao dịch mới.Ngược lại nếu session ID màserver nhận được từ client trùng khớp với session ID client gửi thì phiên giao dịch trước đó

sẽ được bắt đầu lại với session ID này

Nếu server không bắt đầu lại với phiên giao dịch đã thiết lập trước đó , thì gói tin mà nó gửicho client phải bao gồm thông điệp bắt tay ( handshake message) TLS server_certificate vàserver_done_hello handshake message phải là thông điệp bắt tay cuối cùng được đóng góitrong gói tin EAP-Request

Certificate message chứa một chứng chỉ khoá công khai (public key certificate) hoặc là traođổi khoá công khai ( chẳng hạn như RSA hoặc Diffie-Hellman ) hoặc là chữ ký khoá côngkhai ( như là RSA hay DSS-Digital Signature Standard )

Nếu bên phía client hỗ trợ EAP-TLS và được cấu hình để sử dụng giao thức này thì phảiphản hồi gói tin EAP-Request bằng gói tin EAP-Response với type=EAP-TLS.Nếuserver_hello_message trước đó được gửi bởi EAP-Server trong gói tin EAP-Request trước

đó không bắt đầu lại phiên giao dịch trước thì trường dữ liệu của gói tin phải đóng gói bằngmột hoặc nhiều TLS record trong đó chứa TLS client_key_exchange, change_cipher_spec vàfinished message

Nếu EAP-Server gửi một certificate_request_message trong gói EAP-Request trước đó, trừkhi client được cấu hình riêng thì client phải gửi bổ sung certificate vàcertificate_verify_message.EAP-Server sẽ xác nhận certificate của client và chữ ký điện tửnếu server được yêu cầu

Nếu server_hello_message trước đó được gửi từ server nằm trong gói EAP-Request bắt đầulại phiên giao dịch trước thì bên phía client chỉ phải gửi change_cipher_spec và finished_handshake_message ( chứa client authentication phản hồi lại EAP-Server )

2.1.1.1 EAP-TLS Packet Format : (RFC 3748)

Trang 14

Một EAP-TLS packet có cấu trúc như sau :

 Code : code field chiếm 1 octet và nhận dạng các loại gói tin EAP.

 Length: chiếm 2 octet , cho biết độ dài của gói tin.Mỗi octet của gói tin EAP bao

gồm Code, Identifier , Length và Data fields.Những octet nào nằm ngoài giá trịcủa Length field sẽ bỏ qua.Một message với trường độ dài ( Length Field ) nào

mà thiết lập giá trị lớn hơn số lượng các octet nhận được phải được loại bỏ

 Data: có thể là 0 hoặc chiếm nhiều octet.Định dạng của trường dữ liệu được xác

định bởi Code Field

2.1.1.2 EAP-TLS Request Packet : (RFC 5216)

Một EAP-TLS Request Packet có cấu trúc như sau:

Trang 15

 Code : giá trị =1 ( request packet )

 Indentifier : phải được thay đổi trên mỗi Request Packet.

 Length : cho biết độ dài của gói tin EAP bao gồm Code, Identifier , Length ,

Type và Data Field

 Type : nhận giá trị=13 –EAP-TLS.

-Bit M : hiển thị tất cả ngoại trừ fragment cuối

-Bit S : được cài đặt làm EAP-TLS start message, khác biệt với fragmentacknowledgment

-Bit R : bit dự trữ

 TLS Message Length : chiếm 4 octet , trường này chỉ hiện diện nếu bit L bật

lên.Nó cung cấp tổng chiều dài của TLS Message hoặc bộ message đang đượcphân đoạn

Trang 16

 TLS Data : làm nhiệm vụ đóng gói TLS Packet bằng định dạng TLS Record.

2.1.1.3 EAP-TLS Response Packet : (RFC 5216)

Có cấu trúc tương tự EAP-TLS Request Packet

 Code : giá trị = 2 ( response packet ).

 Identifier : chiếm 1 octet, phải trùng khớp với Identifier form request.

 Length : chiếm 2 octet, cho biết độ dài của gói tin EAP bao gồm Code, Identifier,

Length, Type và Data Field.Những byte nào nằm ngoài dãy Lengh Field đượcxemm như là lớp độn data link layer và phải được bỏ qua khi tiếp nhận

 Type: nhận giá trị =13-EAP-TLS.

Trang 17

-Bit R : bit dự trữ.

 TLS Message Length : chiếm 4 octet, chỉ hiện diện nếu bit L bật lên.Trường này

cung cấp tổng chiều dài của TLS Message hoặc bộ message đang được phânđoạn

 TLS Data : làm nhiệm vụ đóng gói TLS Packet bằng định dạng TLS record.

2.1.1.4 EAP-TLS Success and Failure : (RFC 3748)

Gói tin thành công được gửi từ server đến client sau khi hoàn thành bằng phươngpháp chứng thực EAP ( type = 4 hoặc lớn hơn ) để cho biết rằng client đã chứngthực thành công bởi server

Server phải truyền một gói tin EAP với Code = 3 ( success ) Nếu server khôngthể chứng thực được client ( không thể chấp nhận phản hồi từ một hay nhiều yêucầu ) sau khi chứng thực bằng phương pháp EAP kết thúc không thành công, thìphải truyển một gói tin EAP bổ sung với Code = 4 ( failure )

Success & failure packets không được chứa dữ liệu bổ sung và phải không đượcgửi bởi EAP server nếu phương pháp chứng thực không cho phép kết thúc tại thờiđiểm đó

2.1.2 Initial EAP Request / Respones Types (RFC-2284)

2.1.2.1 Identity

Được sử dụng để xác định danh tính của client.Nhà chứng thực sẽ cấp phátyêu cầu lúc ban đầu.Một thôn g báo được hiển thị them có thể gồm dấu nhắclệnh cho client trong trường hợp đang tương tác với người sử dụng.Thông báophản hồi phải được gửi cho bên Request với type = 1

Type: = 1

Type-Data : trường này chưa thông điệp có thể hiển thị bên phản hồi

( Request) Bên phản hồi sử dụng trường này để trả lại Indentity.Nếu Identitykhông rõ ràng thì trường này có chiều dài là 0 octet và không được mang giá

Trang 18

trị rỗng ( NULL ) Trường này có chiều dài nhận từ độ dài của gói tinRequest/Response do đó giá trị NULL là không cần thiết.

2.1.2.2 Notification

Được tuỳ chọn sử dụng để truyền tải thông tin được hiển thị từ nhà chứngthực đến với client.Client nên hiển thị thông tin đến với người sử dụng hoặcđăng nhập vào nếu không thể hiển thị được

Notification được thiết kế để cung cấp thông báo chấp nhận của 1 số tính chấtbắt buộc.Chẳng hạn như 1 mật khẩu sắp hết hạn thì số thứ tự của mật khẩu đógần bằng 0 Hầu hết trong các trường hợp, thông báo trên không được yêucầu

Type: = 2

Type-Data: trường dữ liệu bên Request chứa đúng 1 thông điệp hiển thị có độ

dài lớn hơn 0.Chiều dài của thông điệp này được xác định bởi trường độ dài( Length Field ) của gói tin Request.Các thông điệp không được mang giá trịkết thúc là rỗng ( NULL ).Bên phản hồi ( Response) phải được gửi hồi đápcho bên yêu cầu ( Request ) tới type = 2 ( notification ).Trường dữ liệu ( data-type ) của bên phản hồi có độ dài là 0 octet và phải được gửi ngay lập tức

2.1.2.3 Nak

Chỉ có giá trị trong các tin nhắn phản hồi ( response message ).Nó được gửi đểtrả lời cho bên Request nơi mà nếu kiểu xác thực không thể chấp nhậnđược.Kiểu chứng thực được đánh số thứ tự là 4 và lớn hơn nữa.Bên Responsechứa kiểu chứng thực mà client mong muốn

Type: =3

Type-Data: phải chứ duy nhất 1 octet để chỉ rõ kiểu chứng thực mong muốn.

2.1.2.4 MD5-Challenge

Tương tự như giao thức PPP CHAP.Bên Request chứa 1 “challenge” message

và gửi cho client, bên Response phải được gửi để trả lời cho bên Resquest và

có thể có loại 4 ( MD5-Challenge ) hoặc loại 3 ( Nak ).Việc triển khai EAPphải hỗ trợ cơ chế chứng thực MD5-Challenge

Type : = 4

Type-Data: nội dung của trường dữ liệu này được tóm tắt dưới đây

Trang 19

2.1.2.5 One-Time Password (OPT)

Bên yêu cầu ( Request ) chứa một thông điệp hiển thị gồm 1 OPTChallenge.Bên phía phản hồi ( Response ) phải gửi trả lời cho bên Request vàphải thuộc loại 5 ( OPT ) hoặc 3 ( Nak ).Nak reply cho biết kiểu cơ chế chứngthực mà client mong muốn

Type: =5

Type-Data: OPT Challenge là một thông điệp hiển thị của bên Request.Bên

hồi đáp, trường này được sử dụng cho “6 từ” trong “One-Time PasswordSystem” ( RFC-1938 ).Các thông điệp này không được kết thúc bằng giá trịrỗng ( NULL ).Độ dài của trường này nhận được từ chiều dài của gói tinRequest/Response

2.1.2.6 Generic Token Card

Được định nghĩa để sử dụng với việc triển khai Token Card khác nhau mà yêucầu người sử dụng nhập vào.Bên yêu cầu chứa một tin nhắn dạng văn bảnASCII và bên trả lời chứa tin nhắn Token Card cần thiết cho việc chứngthực.Thông tin này được người sủ dụng đọc từ thiết bị Token Card và nhậpnhư dạng văn bản ASCII

Type: = 6

Type-Data: trường dữ liệu bên yêu cầu chứa thông điệp để hiển thị có độ dài

lớn hơn 0 octet.Chiều dài của thông điệp này được xác định bởi trường độ dài( Length Field ) của gói tin Request và không được mang giá trị rỗng( NULL).Bên phản hồi phải gửi tin nhắn trả lời cho bên yêu cầu với type = 6,

và chứa dữ liệu từ Token Card đòi hỏi việc xác thực.Chiều dài của dữ liệuđược xác định bởi trường dữ liệu của gói tin Response

2.1.3 TLS Protocol (RFC 4346)

Trang 20

TLS Protocol được chia làm hai lớp.Lớp đầu tiên là Handshake Protocol Layerbao gồm ba giao thức con: Handshake Protocol, Change Cipher Spec Protocol vàAlert Protocol.Lớp thứ hai là Record Protocol Layer.

Record Layer Protocol: giao thức ở lớp này nhận và mã hoá dữ liệu từ lớp ứngdụng (application layer) và cung cấp cho lớp vận chuyển(Transport layer ).RecordProtocol lấy dữ liệu, phân mảnh nó cho phù hợp với kích thước của thuật toán mãhoá, áp dụng MAC (Message Authentication code ) hoặc HMAC ( Hash-basedMessage Authentication Code ) và sau đó mã hoá hoặc giải mã dữ liệu bằng cách

sử dụng thông tin đã thoả thuận trước trong Handshake Protocol

Handshake Protocol chịu trách nhiệm cho việc thương lượng phiên giao dịch baogồm các hạng mục sau đây :

 Session Identifier : một chuỗi byte tuỳ ý được lựa chọn bởi máy chủ để

xác định trạng thái phiên giao dịch một cách chủ động hoặc có thể khôiphục lại

 Peer Certificate : chứng chỉ X509v3 [X509] của client, trạng thái này có

thể là Null

 Compression method : thuật toán dùng để nén dữ liệu trước khi mã hoá.

 Cipher spec : chỉ định các thuật toán mã hoá dữ liệu số lượng lớn ( vd như

Null , DES … ) và thuật toán MAC ( MD5 hoặc SHA ), ngoài ra nó cònđịnh nghĩa mã hoá các thuộc tính như kích thước hàm băm ( hash_size )

Trang 21

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

 Resumable: một lá cờ hiệu cho biết rằng liệu phiên giao dịch có thể được

sử dụng để bắt đầu kết nối mới

2.1.3.1 Change Cipher Spec Protocol

Là giao thức tồn tại để báo hiệu quá trình chuyển đổi chiến lược mã hoá.Giaothức gồm một tin nhắn đơn lẻ được mã hoá và nén bằng trạng thái kết nối hiện tại.Message này gồm 1 byte riêng lẻ có giá trị = 1

Sau khi gửi thông điệp này đi, người gửi (sender) phải hướng dẫn cho RecordLayer biết để chuyển sang trạng thái ghi và trạng thái này được kích hoạt.Changecipher spec message được gửi trong suốt quá trình bắt tay ( handshake ) sau khicác thông số bảo mật đạt được thoả thuận nhưng trước khi thông điệp xác nhậnkết thúc ( verifying finished message ) được gửi

Change Cipher Spec Protocol

Trang 22

kết nối khác tương ứng với phiên giao dịch có thể tiến hành tiếp tục nhưng phiêngiao dịch định danh ( session identifier ) phải bị mất hiệu lực và ngăn chặn cácphiên không thành công ( fail session ) được sử dụng cho việc thiết lập kết nốimới.Cũng giống như các tin nhắn khác, tin nhắn cảnh báo được mã hoá và nénnhư được chỉ định trước bởi trạng thái kết nối hiện hành.

Alert Level Types

Alert Description types

2.1.3.3 Handshake Protocol

Trang 23

TLS handshake protocol là một trong những máy trạm được định nghĩa ở mức độcao hơn ( defined higher-level clients ) của TLS Record Protocol.

Giao thức này được sử dụng để thương lượng các thuộc tính bảo mật của mộtphiên

Thông điệp bắt tay được cung cấp cho TLS Record Layer, nơi mà các thông điệpnày được đóng gói trong một hoặc nhiều cấu trúc TLS Plaintext, chúng được xử

lý và truyền đi theo quy định của trạng thái phiên kết nối hiện tại đang hoạt động

TLS Handshake protocol bao gồm các bước sau:

-Exchange hello message đồng ý trao đổi các thuật toán, trao đổi ngẫu nhiên cácgiá trị và kiểm tra phiên tiếp tục

-Trao đổi các thông số mật mã cần thiết để cho phép client và server thoả thuậnpremaster secret key

-Các chứng chỉ trao đổi ( exchange certificates ) và thông tin mật mã cho phépclient và server tự chứng thực

-Tạo ra một master secret key từ premaster secret key và trao đổi các giá trị ngẫunhiên

-Cung cấp các thông số bảo mật cho record layer

-Cho phép client và server xác minh rằng các máy trong cùng đường mạng tínhtoán được các thông số bảo mật và như thế quá trình bắt tay ( handshake ) xảy ra

mà không có kẻ tấn công can thiệp vào

Cấu trúc của giao thức bắt tay:

HandshakeType msg_type; /* handshake type */

uint24 length; /* bytes in message */

select (HandshakeType) {

case hello_request: HelloRequest;

case client_hello: ClientHello;

case server_hello: ServerHello;

case certificate: Certificate;

case server_key_exchange: ServerKeyExchange;

Trang 24

case certificate_request: CertificateRequest;

case server_hello_done: ServerHelloDone;

case certificate_verify: CertificateVerify;

case client_key_exchange: ClientKeyExchange;

case finished: Finished;

} body;

} Handshake;

Chi tiết các gói tin trong Handshake Protocol:

 Hello Message: được sử dụng để trao đổi, tăng cường tính bảo mật giữa

máy trạm và máy chủ Khi một phiên mới bắt đầu, trạng thái kết nối củaRecord Layer sẽ mã hoá, băm và các thuật toán nén được khởi tạo giá trịNull.Trạng thái kết nối hiện tại được sử dụng cho những thông điệpthương lượng lại (renegotiation messages)

 Hello Request : có thể được gửi đi bởi máy chủ ở bất kì thời

điểm nào

Ý nghĩa của message này: Hello Request là một thông báo yêu cầu

client nên bắt đầu quá trình “trao đổi thông tin ” một lần nữa bằngcách gửi cho client một Hello Message khi thuận tiện Thông báo này

sẽ được client bỏ qua nếu client đang thực hiện một tác vụ khác.Hello

Trang 25

Message cũng có thể được client bỏ qua nếu nó không muốn thực hiệntác vụ này, hoặc là client sẽ trả lại một thông báo không chấp nhận tinnhắn Khi gói tin trao đổi được gửi đi nó sẽ được cấp độ ưu tiên caohơn các ứng dụng thông thường, nó sẽ thực hiện việc trao đổi vớiclient khi không nhận được quá nhiều record từ client Nếu như servergửi đi Hello Request nhưng không nhận được phản hồi từ client, nó sẽngắt kết nối của client kèm theo một cảnh báo.Sau khi gửi hellomessage , máy chủ không nên gửi lại các yêu cầu cho đến khi việc traođổi thông tin đã hoàn tất.

Cấu trúc của message này :

struct { } HelloRequest;

Message này không được bao gồm trong những dữ liệu đã bị phân

rã, thứ mà được duy trì trong suốt quá trình trao đổi thông tin vàdùng trong những message kết thúc cũng như chứng thực xác nhậntin nhắn ( certificate verify message)

 Client Hello :

Ý nghĩa của message này : Khi một client kết nối với máy chủ lần

đầu tiên, nó sẽ được yêu cầu gửi client hello message Client cũng

có thể gửi một client hello để phản hồi hello request hoặc dùngmột kiểu dữ liệu của chính bản thân mình để trao đổi các thông sốbảo mật trong một kết nối đã tồn tại

Cấu trúc của message này :

+client_version : c ác phiên bản của giao thức TLS mà client muốn dùng để giao tiếp trong session này, nên xài những phiên bản mới nhất.

+Random : do client tạo ra một cách ngẫu nhiên.

+Session_id : ID của session mà client muốn dùng để thực hiện kết nối thông số này nên để trống nếu không có session_ID nào tồn tại hoặc nếu client muốn tạo ra các thông số bảo mật mới.

Trang 26

+Cipher_suites : danh sách các tuỳ chọn mã hoá được hỗ trợ bởi client, với ưu tiên cho client đầu tiên Nếu vùng session_id rỗng thì phải bao gồm ít nhất cipher_suite từ session đó.

+Compression_methods : là danh sách các phương thức nén hỗ trợ bởi client, sắp xếp theo yêu cầu của client Nếu vùng session_id rỗng, nó phải bao gồm các compression_method từ session đó

Sau khi gửi client hello meassage, client sẽ đợi để nhận server hello message Bất kì thông điệp bắt tay (handshake message) nào khác được trả về bởi máy chủ ngoài hello request được xem là một lỗi nghiêm trọng.

 Server Hello:

Ý nghĩa của message này: server gửi cho client gói tin hellomessage khi có thể tìm thấy một tập hợp các thuật toán có thể chấpnhận được Nếu không thể tìm thấy cái nào trùng khớp, nó sẽ phảnhồi một cảnh bảo là quá trình bắt tay thất bại ( handshake failurealert)

Cấu trúc của message này:

+Server version : thông số này chứa những đề nghị thấp hơn của

client trong client hello message và những hỗ trợ cao nhất từ server.

+Random : được tạo ra bởi server và phải được tạo ra độc lập từ client hello random

+Session_id : là danh tính của một phiên tương ứng với kết nối này Nếu clienthello.session_id không rỗng (non-empty) thì server sẽ tìm trong bộ nhớ cache của phiên đó một mẫu tin trùng khớp Nếu một mẫu tin trùng khớp được tìm ra và máy chủ sẵn sàng thiết lập kết nối mới bằng cách sử dụng các session quy định thì server sẽ phản hồi lại một giá trị tương tự như giá trị đã được cung cấp

Trang 27

bởi client.

+Cipher_suite : bộ mã hoá được lựa chọn bởi máy chủ từ danh sách trong ClientHello.cupher_suites Đối với session được khởi động lại, vùng này mang giá trị từ session đã được khởi động +compression_method : các phương thức nén được lựa chọn bởi server từ danh sách clienthello.compression_methods.Đối với các phiên khởi động lại (resumed session) thì trường này là giá trị của trạng thái bắt đầu lại.

 Server Certificate: server phải gửi một chứng thực (certificate) bất cứ

khi nào các phương pháp trao đổi khoá được truyền đi không phải là từ một địa chỉ vô danh (anonymous) Message này sẽ luôn kèm theo server hello message

 Ý nghĩa của message này: các dạng certificate phải tương thích với

các thuật toán trao đổi khoá của bộ mã hoá được lựa chọn.Nó phảichứa một khoá phù hợp với phương thức trao đổi khoá Trừ khi có quyđịnh riêng, thuật toán chữ ký dùng cho việc chứng thực.phải đồng bộvới thuật toán cho việc chứng thực khoá và khoá công cộng có thể cóchiều dài bất kì

 Server Key Exchange Message: message này được gửi đi ngay sau

server certificate message (hoặc server hello message, nếu từ anonymousnegotiation) Server key exchange message được gửi đi bởi server chỉ khiserver certificate message không chứa đủ dữ liệu để cho phép client tiếnhành trao đổi premaster secret key và đúng với các phương pháp trao đổikhoá như DHE_DSS, DHE_RSA, DH_anon nhưng không hợp lệ với cácphương pháp khác như RSA, DH_DSS, DH_RSA

 Ý nghĩa của message này : message này truyền tải thông tin mật mã

cho phép client giao tiếp với premaster secret, cũng như khoá côngcộng RSA để mã hoá premaster secret key hoặc khoá công cộngDiffie-Hellman mà client có thể hoàn tất việc trao đổi khoá

 Cấu trúc của message này:

enum { rsa, diffie_hellman } KeyExchangeAlgorithm;

Trang 28

+rsa_exponent: bậc luỹ thừa của khoá tạm thời RSA.

Diffie-+dh_g: bắt đầu việc dùng thuật toán Diffie-Hellman

+dh_Ys: giá trị công cộng của thuật toán Diffie-Hellman (g^X mod p).

+Param: các thông số của server’s key exchange.

+Signed_params: đối với việc trao đổi khoá non-anonymous ,quá

trình phân rã tương ứng với giá trị params, với chữ ký (signature) phù hợp với hàm băm (hash) được áp dụng

+md5_hash: MD5 (ClientHello.random + ServerHello.random + ServerParams).

+sha_hash : SHA (ClientHello.random + ServerHello.random + ServerParams).

enum { anonymous, rsa, dsa } SignatureAlgorithm;

struct {

select (SignatureAlgorithm) {

Trang 29

case anonymous: struct { };

 Ý nghĩa của message này: Một non-anonymous server có thể yêu cầu

một certificate từ client nếu nó phù hợp với bộ mã hoá được chọn.Nếu thông báo này được gửi thì ngay lập tức sẽ thực hiện theo ServerKey Exchange Message

+Certificate authorities: tập danh sách những tên phân biệt của trung tâm

uỷ quyền chứng thực mà có thể chấp nhận được, có thể được dùng để chỉ định root CA hoặc CA cấp dưới của nó.

Trang 30

Giá trị của ClientCertificateType được chia làm 3 nhóm sau :

o Giá trị từ 0 (zero) đến 63 lưu trữ cho giao thức IETF StandardTrack

o Giá trị nhận từ 64 đến 223 được lưu trữ cho phương thức Standards Track

non-o Giá trị từ 224 đến 225 được dùng cho mục đích sử dụng riêng

 Server Hello Done:

Server hello done được gửi đi từ server để chỉ định việc kết thúc server hello và những tin nhắn liên quan Sau khi tin nhắn được gửi đi, server sẽ chờ hồi đáp từ client

 Ý nghĩa của message này: khi server hoàn tất việc gửi tin nhắn để

hỗ trợ quá trình trao đổi khoá và sau đó client có thể tiến hành giaiđoạn trao đổi khoá đó.Dựa vào server hello done message này,client nên xác nhận lại rằng server cung cấp một chứng nhận hợp

lý nếu cần thiết và kiểm tra các thông số của server hello message

để chấp nhận

struct { } ServerHelloDone;

 Client Certificate: là thông điệp đầu tiên mà client có thể gửi sau khi

nhận được server hello done message.Tin nhắn này chỉ được gửi nếuserver yêu cầu chứng nhận.Nếu không có sẵn chứng nhận phù hợp có sẵnthì client nên gửi certificate message nội dung là không nhận được chứngnhận

 Client Key Exchange Message : thông điệp này luôn được gửi đi từ

client Nó phải lập tức gửi theo sau client certificate message nếu nó đượcgửi đi

Trang 31

Ngược lại, nó phải là thông điệp đầu tiên được gửi từ client sau khi nhậnđược server hello done message.

 Ý nghĩa của message này: với thông điệp này, khoá premaster

secret được thiết lập mặc dù cả hai đều nhằm vào việc truyền dẫntrực tiếp của khoá mã hoá bí mật RSA bởi những thông số củathuật toán Diffie-Hellman, việc này sẽ cho phép mỗi bên thoảthuận cùng một premaster secret key

Nếu phương pháp trao đổi khoá là DH_RSA hoặc DH_DSS thìchứng nhận của client đã được yêu cầu và client có thể đáp ứngmột chứng nhận chứa đựng khoá công khai Diffie-Hellman mànhững thông số đó phải phù hợp với những quy định của server,thông điệp này không chứa bất kỳ dữ liệu nào

struct {

select (KeyExchangeAlgorithm) {

case rsa: EncryptedPreMasterSecret;

case diffie_hellman: ClientDiffieHellmanPublic; } exchange_keys;

} ClientKeyExchange;

 RSA Encrypted Premaster Secret Message :

Ý nghĩa của message này: RSA được sử dụng như là khóa thoả

thuận và chứng thực Client sẽ tạo ra khoá premaster secret cóchiều dài là 48 byte và mã hoá khoá này bằng khoá công khai từserver certificate hoặc khoá tạm thời RSA được cung cấp trongserver key exchange message.Sau đó client se gửi kết quả đó bằngtin nhắn đã mã hoá premaster secret

Trang 32

+Random: 46 byte ngẫu nhiên được tạo ra đảm bảo tính an toàn struct {

public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret;

+Pre_master_secret: giá trị ngẫu nhiên được tạo ra bởi client và được sử dụng trong việc tạo ra khoá master_secret.

 Client Diffie-Hellman Public Value :

Ý nghĩa của message này: cấu trúc này truyền đạt giá trị công

khai Diffie-Hellman của client (gọi tắt là Yc), nó không bao gồmcác chứng nhận của client (Client Certificate).Yc được xác địnhbởi PublicValueEncoding, cấu trúc này là một biến thể của clientkey exchange message

enum { implicit, explicit } PublicValueEncoding;

+Implicit: nếu chứng nhận của client đã chứa khoá Hellman phù hợp thì Yc là implicit và không cần gửi lại nữa.Trong trường hợp này, client key exchange message sẽ được gửi nhưng phải mang giá trị rỗng.

Diffie-+Explicit: Yc cần được gửi.

struct {

select (PublicValueEncoding) {

case implicit: struct { };

case explicit: opaque dh_Yc<1 2^16-1>;

} dh_public;

} ClientDiffieHellmanPublic;

+dh_yc: The client’s Diffie-Hellman public value (Yc).

 Certificate Verify :

Ý nghĩa của message này : được sử dụng để xác minh rõ ràng việc cung

cấp chứng nhận cho client.Thông điệp này chỉ được gửi sau khi clientmessage có hiệu lực.Khi gửi đi nó phải lập tức kèm theo client keyexchange message

Trang 33

 Finished Message : được gửi ngay sau change cipher spec message để

xác minh rằng việc trao đổi khoá và quá trình chứng thực thànhcông.Change cipher spec message được nhận giữa các thông điệp bắt taykhác (other handshake message) và finished message

Ý nghĩa của message này: được bảo vệ đầu tiên bằng các thuật toán được

thoả thuận trước, khoá và khoá bí mật.Finished message của client phảixác minh rằng nội dung là chính xác Một khi một bên đã gửi finishedmessage, nhận được và xác nhận từ client của nó thì có thể bắt đầu gửi vànhận dữ liệu thông qua kết nối đó

+Finish Label: nếu là được gửi từ client thì sẽ thông báo là “client

finish”, nếu được gửi từ server thì sẽ thông báo là “server finish”.

+Handshake_message: tất cả dữ liệu từ các thông điệp trong giao thức bắt tay này ( không bao gồm hello request message ) không bao gồm message này Chỉ có dữ liệu được nhìn thấy ở handshake layer và không bao gồm header record layer.Đây là mắc xích của cấu trúc bắt tay ( handshake structure )

2.1.3.4 Application Data Protocol

Những thông điệp dữ liệu tầng ứng dụng được thực hiện bởi Record Layer vàđược phân đoạn ,nén mã hoá dựa trên trạng thái kết nối hiện hành Các tin nhắnđược xem như là dữ liệu trong suốt đối với Record Layer

Trang 34

-Length: chiều dài của dữ liệu tầng ứng dụng

-MAC: 20 bytes cho thuật toán SHA-1 dựa trên HMAC và 16 bytes cho thuật

toán MD5

-Padding: chiều dài có thể thay đổi, byte cuối cùng chứa padding length.

Trang 35

CHƯƠNG III: THỰC NGHIỆM MINH HOẠ

3.1.Mô hình thực nghiệm :

Mô hình sử dụng phần mềm giả lập máy ảo VMWare Workstation 7 gồm :

-Máy Domain Controller (DC) : Windows Server 2003 SP2

-Máy IAS Server : Windows Server 2003 SP2

-Máy chủ dịch vụ : Web, Mail, FTP…

IP: 192.168.1.100 SM: 255.255.255.0 GW: 192.168.1.1 DNS: 192.168.1.100

Trang 36

IAS – Windows 2k3 RADIUS Server

IP: 192.168.1.200 SM: 255.255.255.0 GW: 192.168.1.1 DNS: 192.168.1.100

IIS – Windows 2k3

Web Server File Server

IP: 192.168.1.250 SM: 255.255.255.0 GW: 192.168.1.1 DNS: 192.168.1.100

Thông số máy Domain Controller

Trang 37

Thông số máy IAS (Internet Authentication Service)

Trang 38

Thông số máy IIS Server ( Web, File Server…)

 Domain Controller:

-Raise domain functional level

-Cài đặt và cấu hình DHCP

-Cài Certificate Services

-Verify Administrator permission for certificates

-Cấp quyền Allow Wireless for User and Computer

-Install Certificate Template Snap-in

-Create Certificate Template for wireless users

-Configure Certificate Template

-Enable Certificate Template

 IAS Server:

-Cài đặt và cấu hình Internet Authentication Service (IAS).-Xin Certificate cho Computer Account

-Tạo RADIUS Client

-Tạo và cấu hình Remote Access Policy

- Configure IAS to use EAP-TLS Authentication

-Cấu hình Windows Firewall

 IIS Server:

-Cài đặt Internet Information Service, tạo trang web default.-Cấu hình Shared Folder

Trang 39

-Cấu hình Windows Firewall.

 Wireless Access Point:

-Cấu hình 802.1x, khai báo RADIUS Server

 Client:

-Cấu hình Wireless Network Connection.-Configure to use EAP-TLS authentication.-Kiểm tra kết nối

3.2 Các bước cài đặt chi tiết :

 Domain Controller:

Trang 40

Raise Domain Functional Level

Tạo Scope cấp IP cho client- Range IP : 192.168.1.10 – 192.168.1.20 – SM : 24

Định dạng
Số trang	86
Dung lượng	3,56 MB