4.3.2.1 Các phương thức xác thực
Có hai phương thức xác thực nguồn gốc dữ liệu: xác thực dựa trên mật khẩu và xác thực dựa trên giao thức hỏi đáp.
a) Phương thức xác thực dựa trên mật khẩu
Đối với phương thức này, tồn tại 2 nguy cơ mất an toàn như sau:
Phía thu Kênh truyền Phía phát 1 0 1 0 1 1 1 0 0 1 0 1 0 0 1 1 0 1 1 1 0 1 0 0 0 1 0 1 0 1 Hàm băm Chữ ký Giá trị băm Mật mã cùng với khóa riêng 1 0 1 0 1 1 1 0 0 1 0 1 0 0 1 1 0 1 1 1 0 1 0 0 0 1 0 1 0 1 Chữ ký Giá trị băm Giải mã cùng với khóa công cộng Giá trị băm So sánh
- Nguy cơ thứ nhất: Mật khẩu phải truyền qua một kênh không an toàn. Ví dụ trong trường hợp đăng nhập từ xa sử dụng giao thức telnet yêu cầu truyền nhận dạng (ID) và mật khẩu (password) của người sử dụng ở dạng bản rõ tới máy đích. Như vậy nguy cơ mất an toàn là cao vì phải truyền mật khẩu qua Internet - một kênh không an toàn.
- Nguy cơ thứ hai: mật khẩu phải được lưu trong một phương tiện lưu trữ của máy chủ, thông thường là máy chủ đăng nhập (login server). Việc lưu trữ mật khẩu cũng là một nguy có mất an toàn cao.
b) Phương thức xác thực dựa trên các giao thức hỏi đáp
Để xác thực qua một kênh không an toàn, có thể sử dụng một giao thức hỏi đáp để kiểm tra xem đối tác cần xác thực có sở hữu một giá trị bí mật để xác thực đối tác đó hay không. Phương thức này không yêu cầu phải trao đổi các giá trị bí mật thông qua kênh không an toàn. Giao thức hỏi đáp này sử dụng mã xác thực bản tin MAC hoặc chữ ký số.
Giao thức hỏi đáp sử dụng mã xác thực bản tin MAC
Hình 4.15: Giao thức hỏi đáp MAC
Phương pháp này sử dụng một khóa bí mật chung giữa hai đối tác. Chẳng hạn khi một người sử dụng muốn đăng nhập vào một máy chủ, máy chủ sẽ gửi một câu khẩu lệnh (challenge) tới người sử dụng, dứoi dạng một giá trị ngẫu nhiên (gọi là nonce). Để đề phòng tấn công kiểu lặp lại, mỗi giá trị nonce thường không được sử dụng đến lần
Giá trị ngẫu nhiên (Nonce)
Kênh không an toàn
IDU RU RS
Key Keyed Hash Function
IDU RU MAC IDU RU RS
RS
Key Keyed Hash Function MAC MAC Khẩu lệnh Đáp ser Server
thứ hai. Người sử dụng tạo ra một trả lời (response) bằng cách ghép các giá trị ngẫu nhiên RS (nhận được từ máy chủ) với thông số nhận dạng ID của người đó, sau đó đưa tới một hàm băm có sử dụng khóa được khởi tạo bởi một khóa bí mật. Bản thân hàm băm để tăng tính an toàn. Kết quả của hàm băm là mã MAC, cùng với thông số nhận dạng ID sẽ được gửi tới máy chủ. Với đặc tính một chiều của MAC, dữ liệu được truyền đi trên kênh không an toàn sẽ không để lộ bất cứ thông tin nào về khóa bí mật.
Máy chủ dựa vào các thông tin mà nó có (bao gồm ID, RU, RS, khóa bí mật) để tính giá trị MAC, sau đó so sánh với MAC mà người sử dụng gửi đi. Nếu người sử dụng có đúng khóa bí mật sử dụng chung thì hai giá trị này trùng khớp với nhau và quá trình xác thực thành công.
Giao thức xác thực sử dụng chữ ký số
Giao thức hỏi đáp cũng có thể dựa trên chữ ký số, sử dụng mật mã khóa công khai. Người sử dụng là người duy nhất có khóa bí mật, còn một server bất kỳ đề có khóa công khai tương ứng của người sử dụng đó nếu muốn xác thực. Người sử dụng tạo ra một mã hash từ các thông tin: ID, RS (nhận được từ máy chủ như một khẩu lệnh), RU. Bằng cách mật mã giá trị hash với khóa bí mật, sẽ tạo thành một chữ ký số để gửi lại máy chủ (như một trả lời).
Các hệ thống mật mã khóa công khai đã trở nên thông dụng vì khóa công khai không cần phải giữ bí mật và do đó có thể được phân phối một cách rộng rãi. Vì vậy, khi một máy chủ xác thực một người sử dụng bằng cách kiểm tra chữ ký trên cơ sở khóa công khai của người sử dụng đó thì vấn đề đặt ra là liệu cặpkhóa công khai/ bí mật sử dụng trong quá trình xác thực có thực sự thuộc về người sử dụng này hay không.
Hình 4.16: Giao thức hỏi đáp sử dụng chữ ký số
Nếu khóa công khai sử dụng trong quá trình xác thực được lấy từ một thư mục công cộng thì một tấn công kiểu trung gian (man-in-the-middle attack) có thể dễ dàng thay thế khóa công khai của người sử dụng bằng một khóa công khai của kẻ tấn công. Đây chính là nguyên nhân dẫn đến việc hình thành các chứng thực (certificate). Các chứng thực thiết lập một mối liên hệ tin cậy giữa nhận dạng người sử dụng và khóa công khai của người đó.
4.3.2.2 Các chứng thực số (digital certificates)
a) Mô hình tin tưởng thứ nhất
Một phương pháp để thiết lập tin tưởng đối với khóa công khai của người sử dụng là cách tiếp cận mạng tin tưởng (web of trust) đã được sử dụng bởi gói phần mềm mật mã và xác thực thư điện tử PGP (Pretty Good Privacy). Ví dụ trong hình 4.17, C có thể tin tưởng A thông qua 3 đường liên kết trung gian.
Giá trị ngẫu nhiên (Nonce) Kênh không an toàn IDU RU RS Hash ID U R U Sig IDU RU RS RS
Giải mã với khóa công khai Sig Khẩu lệnh Đáp ser Server Mật mã với khóa bí mật Hash Hash
Hình 4.17: Mô hình tin tưởng thứ nhất (PGP Web of Trust)
Trong mạng tin tưởng, mỗi đối tác tham gia sẽ yêu cầu các đôi tác khác ký vào mã hash của chứng thực (chưa nhận dạng, chẳng hạn địa chỉ email và khóa công khai) của đối tác đó. Giả sử C nhận được một email ký gửi bởi A, C sẽ lấy chứng thực của A từ một thư mục công cộng và thấy rằng chứng thực đó đã được ký bởi B. Tiếp theo, C lấy chứng thực của B và thấy rằng nó đã được ký bởi D. Tiếp theo, C lấy chứng nhận của D và thấy rằng nó đã được ký bởi chính mình. Đến đây, các mắt xích đã hoàn tất và có thể thiết lập tin tưởng A.
Cách tiếp cận kiểu mạng tin tưởng chỉ thích hợp với một nhóm nhỏ người sử dụng. Khi số người cần được xác thực tăng lên, chẳng hạn hàng triệu người, số lượng các đường liên kết trung gian trung bình tăng và kéo theo tăng việc tìm các chứng thực. Ngoài ra, khi số các mắt xích tin tưởng tăng thì độ tin cậy cũng giảm đi. Ưu điểm của mạng tin tưởng là không cần sự có mặt của một nhà phân phối trung tâm (central authority).
b) Mô hình tin tưởng thứ hai
Mô hình tin tưởng thứ hai phân cấp tin tưởng với các nhà phân phối chứng thực CAs (Certificate Authorities). Hiện nay mô hình này được lựa chọn để triển khai và sử dụng các chứng thực với qui mô lớn. các mắt xích tin tưởng ở dạng phân cấp: trên cùng là các nhà phân phối chứng thực gốc, tiếp theo là các nhà phân phối chứng thực trung gian.
Can C trust A ? Trust A Signed by B Certificate C Signed by D Certificate B Signed by A D Signed by B Signed by D Signed by C Trust Trust
Hình 4.18: Mô hình tin tưởng thứ hai (phân cấp tin tưởng với các CAs)
Các nhà phân phối chứng thực gốc (Root CAs)
Tại mức trên cùng của phân cấp các mắt xích tin tưởng là một số nhà phân phối chứng thực gốc. Các Root CAs được dùng phổ biến là: Verisign, RSA, Baltimore, Rntrust, Deutsche Telekom và Swisskey.
Các nhà phân phối chứng thực trung gian (Intermediate CAs)
Root CAs có thể trực tiếp cấp phát các chứng thực cho người sử dụng. Tuy nhiên đối với các tổ chức trung bình hoặc lớn thì sẽ thuận lợi hơn nhiều nếu tự thiết lập lấy một CS, khi đó họ có thể tự cấp phát hoặc hũy bỏ các chứng thực cho các các nhân trong tổ chức. Bản thân chứng thực của CA trung gian này thường được cấp phát với ký tự Root CA.
Về nguyên tắc thì có thể thực hiện một số tùy ý các phân cấp, nhưng thông thường chỉ sử dụng từ hai đến ba cấp từ chứng thực của người sử dụng đến Root CA.
Cấu trúc chung của một chứng thực X.509
Mạng tin tưởng thường sử dụng chứng thực OpenPGP (RFC 2440). Còn mô hình phân cấp tin tưởng thường sử dụng chứng thực ITU-T X.509 (RFC 2459).
Client Certificate Trust Verisign Self Signed Amazon Verisign Bob Amazon Alice Amazon Carol Swisskey Swisskey Self Signed Intermediate CA Root CA
Hình 4.19: Cấu trúc chung của một chứng thực X.509
Một chứng thực X.509v3 bao gồm 3 phần - Phần thân của chứng thực.
- Định nghĩa thuật toán sử dụng bởi CAs để ký chứng thực.
- Chữ ký đảm bảo tính xác thực của chứng thực, bao gồm mã hash của phần thân chứng thực được mật mã với khóa bí mật của CAs.
Riêng phần thân của chứng thực bao gồm các thông tin sau:
• Version Number (số phiên bản): hiện tại có các phiên bản v1, v2, v3. • Serial Number: duy nhất được cấp bởi SA tương ứng.
• Signature (chữ ký) và Issure: mô tả thuật toán được sử dụng để chứng thực. • Nhận dạng (ID) của CA phát hành và ký chứng thực.
• Nhận dạng (ID) của đối tượng sử dụng. • Khóa công khai của đối tượng sử dụng. • Các mở rộng tùy chọn của v2 hoặc v3.
Signature SignatureAlgorithm* Version Serial Number Signature* Issuer Validity Subject SubjectPublicKeyInfo IssuerUniqueID Optional SubjectUniqueID Optional Extensions Optional Hash/ Fingerprint Hàm hash Encryption with Issure’s Private Key
CHƯƠNG 5 THỰC HIỆN IP-VPN 5.1 Giới thiệu
Các chương trước đã trình bày về những kỹ thuật cơ bản của IP-VPN bao gồm các giao thức đường ngầm, thuật toán mật mã và xác thực. Các kỹ thuật này hiện đã được giải quyết tích hợp sẵn trong các sản phẩm của nhiều hãng trên thế giới. Do hiện nay chưa có một chuẩn thống nhất cho việc sản xuất các thiết bị VPN, nên vấn đề đặt ra là sự tương thích giữa các sản phẩm của các hãng khác nhau. Người sử dụng cần phải được đảm bảo rằng thiết bị mà họ mua có thể làm việc tốt với các thiết bị khác trong mạng. Để giải quyết vấn đề này, từ năm 2000 VPNC (Virtual Private Network Consortium) đã tổ chức kiểm tra và cấp chứng chỉ cho các sản phẩm IP-VPN đạt yêu cầu về tính tương thích (VPNC Testing for Interoperability and Conformance). Sau đây là danh sách một số sản phẩm đã qua kiểm tra của VPNC:
- ADTRAN, NetVanta.
- Alcatel, Secure VPN Gateway 7130 series. - Check Point Software, VPN-1 Gateway. - Cisco, IOS IPSec.
- Cisco, VPN 3000 Concentrator. - Cylink, NetHawk.
- NetScreen, NetScreen family. - Nokia, Nokia VPN.
- SafeNet, SafeNet family.
- SSH Communications Security, IPSec Express.
- WatchGuard Technologies, WatchGuard Firebox Vclass.
Như vậy đã có nhiều hãng tham gia nghiên cứu, phát triển các thiết bị VPN. Bản thân mỗi hãng lại có nhiều dòng sản phẩm phục vụ cho nhiều nhu cầu ứng dụng khác nhau. Các sản phẩm có thể là chuyên dụng (phục vụ riêng cho mục đích VPN) hoặc kết hợp (chức năng VPN được đi kèm với các chức năng khác, chẳng hạn như router, firewall). Do chưa tồn tại một chuẩn chung nên cách thức sử dụng, cấu hình các sản phẩm này cũng khác nhau. Mục đích của chương này là đưa ra các nguyên tắc và mô hình thực hiện VPN nói chung và giới thiệu qua về tình hình thị trường VPN của Việt Nam.