Thành phần cốt lừi của hệ thống PKI là cỏc chứng thực điện tử, trờn đú chứa hai thành phần thụng tin cơ bản là định danh và khoỏ cụng khai của đối tượng sử dụng.. Cỏc phần tử cơ bản của
TỔ NG QUAN V Ề PKI
Khái quát
TCP/IP được coi là ngôn ngữ chính của Internet, trong khi PKI đóng vai trò quan trọng trong việc bảo đảm an toàn cho việc trao đổi thông tin qua ngôn ngữ này PKI tạo dựng sự tin cậy dựa trên hạ tầng TCP/IP, góp phần nâng cao tính bảo mật trong các giao dịch trực tuyến.
PKI được xây dựng trên nền tảng các kỹ thuật mã hóa, với thành phần cốt lõi là các chứng thực điện tử chứa thông tin định danh và khóa công khai của người sử dụng Các chứng thực này được tạo ra và ký bởi cơ quan chứng thực điện tử (CA - Certification Authority) thông qua chữ ký số Trong hệ thống PKI toàn diện, cơ quan quản lý đăng ký cấp phát chứng thực (RA - Registration Authority) thường được tách biệt khỏi CA, có nhiệm vụ xác minh đối tượng truyền thông mà không tạo ra các chứng thực điện tử.
CA sẽ cấp phát chứng thực điện tử cho đối tượng đó
PKI, hay Hạ tầng Khóa Công khai, là một dịch vụ nền tảng quan trọng cho các dịch vụ an ninh dựa trên chứng thực điện tử Trong các hệ thống này, PKI đóng vai trò chủ chốt trong việc đảm bảo tính an toàn và bảo mật thông tin.
K ỹ thu t m ậ ậ t mã
vai trò thiết lập, quản lý và phát hành chứng thực điện tử cho các đối tượng truyền thông.
Khi dữ liệu được truyền qua Internet, chúng có nguy cơ bị tin tặc phát hiện và lộ ra Để bảo vệ dữ liệu, cách tốt nhất là mã hóa chúng thành một dạng vô nghĩa theo một trật tự nhất định Quá trình này được gọi là mã hóa dữ liệu (encryption) Khi nhận được dữ liệu đã mã hóa, bên nhận có thể giải mã (decryption) để khôi phục lại thông tin về dạng có nghĩa ban đầu.
Nhiều thuật toán đã được phát triển để giải thích cách mã hóa dữ liệu Phần lớn các kỹ thuật mật mã hiện nay đều sử dụng phương pháp “mật mã khóa bảo mật”.
“mật mã khoá công khai”.
1.2.1 Mật mã khoá bảo mật
Trong mã hóa khoá bảo mật, một khoá duy nhất, được gọi là khoá đối xứng hay khoá bí mật, được sử dụng cho cả hai quá trình mã hóa và giải mã Điều này giải thích lý do tại sao việc bảo vệ khoá này là rất quan trọng trong việc đảm bảo an toàn thông tin.
Mật mã khoá bảo mật, hay còn gọi là mật mã khoá đối xứng, đảm bảo an toàn dữ liệu bằng cách khiến cho đối tượng thứ ba không thể hiểu dữ liệu đã được mã hoá Quá trình mã hoá và giải mã sử dụng một khoá bí mật thường nhanh chóng và dễ dàng hơn do thuật toán yêu cầu tính toán ít phức tạp hơn so với mật mã khoá công khai Mật mã khoá bảo mật đóng vai trò quan trọng trong việc mã hoá và giải mã dữ liệu trong nhiều giao thức bảo mật trên Internet, như SSL Một số thuật toán phổ biến cho hệ thống mật mã khoá đối xứng bao gồm DES, Triple DES, IDEA, RC2, RC4, RC5, RC6, và CAST−128, trong đó DES ít được sử dụng do nghi ngờ về khả năng an toàn của nó.
Hình 1.1 Mật mã khoá đối xứng
1.2.2 Mật mã khoá công khai
Mật mã khóa công khai (Public Key Cryptography) sử dụng một cặp khóa bất đối xứng gồm khóa công khai và khóa bí mật Người sở hữu chỉ cần bảo vệ khóa bí mật, trong khi khóa công khai có thể công bố trên mạng Thuật toán liên quan đảm bảo rằng một bản tin mã hóa bằng khóa này chỉ có thể được giải mã bằng khóa còn lại, và không thể sử dụng khóa đã dùng để mã hóa để giải mã Nguyên tắc này cho phép người nhận xác nhận bản tin được gửi từ ai, đặc biệt khi khóa bí mật của người gửi được sử dụng để mã hóa, tạo ra khái niệm “chữ ký số”.
Hình 1.2 Mật mã khoá công khai
Cặp khoá bất đối xứng, được tạo ra bởi thuật toán tính toán phức tạp, mang lại tính bảo mật cao hơn so với khoá đối xứng Mặc dù khoá công khai được phổ biến rộng rãi, các máy tính không thể tính toán để tạo ra khoá bí mật tương ứng, điều này giúp tăng cường bảo mật Tuy nhiên, kỹ thuật này yêu cầu thời gian mã hoá lâu hơn, đặc biệt với dữ liệu lớn, nên thường chỉ được sử dụng để mã hóa một phần thông điệp thay vì toàn bộ.
12 hoá một phần nhỏ dữ liệu được tạo ra từ bản tin Vấn đề này sẽ được trình bày ở phần “chữ ký số”.
Một số các hệ thống mật mã được dùng cho kỹ thuật khoá công khai gồm: RSA, ECC DSA ,
1.2.3 Kết hợp kỹ thuật mã hoá đối xứng và bất đối xứng
Mật mã khoá công khai có nhược điểm là quá trình mã hoá chậm do khoá dài (1024-4096 bit), trong khi mật mã khoá bảo mật nhanh hơn nhờ khoá ngắn hơn (40-256 bit) Tuy nhiên, mật mã khoá bảo mật gặp khó khăn trong việc trao đổi khoá bí mật giữa các bên tham gia truyền thông Việc quản lý khoá cũng trở nên phức tạp khi một người cần giao tiếp với nhiều người khác, vì mỗi người phải giữ N-1 khoá khác nhau Kết hợp hai kỹ thuật này có thể tạo ra phương pháp mã hoá tối ưu hơn, tận dụng ưu điểm của cả hai để khắc phục nhược điểm của chúng.
Để đảm bảo an toàn cho dữ liệu trao đổi, mã hóa dữ liệu cần sử dụng khóa đối xứng (khóa bí mật) Quá trình này bao gồm việc sử dụng mã hóa bất đối xứng (mã hóa khóa công khai) để mã hóa khóa đối xứng bằng khóa công khai của người nhận Sau khi mã hóa, khóa đối xứng sẽ được gửi đến người nhận, người sẽ sử dụng khóa bí mật của mình để giải mã và thu hồi khóa đối xứng từ phía người gửi.
Bên gửi sẽ cung cấp dữ liệu thực sự dưới dạng mã hóa, trong khi bên nhận sẽ sử dụng khóa đối xứng đã nhận trước đó để giải mã và lấy được thông tin cần thiết.
Hình 1.3 Kết hợp hai kỹ thuật mật mã trong tuyền tin
Kỹ thuật kết hợp hai kiểu mật mã được áp dụng phổ biến trong giao thức SSH để bảo vệ thông tin giữa máy chủ và máy khách, cũng như trong giao thức SSL nhằm tạo ra kênh thông tin an toàn giữa trình duyệt Web và máy chủ Web.
Các phần tử cơ bản của hệ thống PKI
Trong phần trước, chúng ta đã thảo luận về mật mã khóa công khai và nhận thấy một số vấn đề cần được giải quyết Khi người gửi sử dụng khóa công khai của người nhận để mã hóa thông tin, người nhận có thể dùng khóa bí mật của mình để giải mã và đọc nội dung, nhưng họ không thể chắc chắn về danh tính của người gửi Một vấn đề khác là khi người gửi
Khi người gửi "ký" bản tin bằng khoá bí mật của mình, người nhận sẽ sử dụng khoá công khai để giải mã thông tin Tuy nhiên, người nhận không thể xác minh chắc chắn rằng khoá công khai đang sử dụng thực sự thuộc về người gửi, vì không có ai có thể xác nhận danh tính của khoá công khai đó.
Kỹ thuật mật mã khoá công khai đóng vai trò quan trọng trong thiết kế an toàn bảo mật thông tin, đặc biệt là thông qua các ứng dụng như chữ ký số và chứng thực điện tử Những ứng dụng này giúp giải quyết hiệu quả các vấn đề liên quan đến bảo mật thông tin, đảm bảo tính toàn vẹn và xác thực trong giao dịch điện tử Việc áp dụng các phương pháp này không chỉ nâng cao độ tin cậy mà còn bảo vệ thông tin cá nhân và dữ liệu nhạy cảm khỏi các mối đe dọa tiềm ẩn.
RA RA Đăng tải thẻ xác nhận
"out-of-band" Đăng ký/xác thực ban đầu Khôi phục cặp khoá
Cập nhật thẻ xác nhận Yêu cầu huỷ bỏ
Phát hành thẻ xác nhận Phát hành danh sách thẻ cần huỷ bỏ
Phát hành thẻ xác nhận
Xác nhận ngang hàng Cập nhật thẻ xác nhận ngang hàng Đối tợng sử dụng
CA1 CA1 CA1 CA1 CA1
CA2 CA2 CA2 CA2 CA2
Hình 1.4 Các phần tử trong hệ thống PKI
Các thuật toán mã hóa thường được công khai, cho phép mọi người nghiên cứu, nhưng chính "khóa" mới là yếu tố bảo vệ dữ liệu Để đảm bảo an toàn, khóa bí mật cần được giữ kín và không để lộ ra ngoài Hơn nữa, cặp khóa bất đối xứng phải được tạo ra thông qua các tính toán phức tạp, và khóa bí mật trong cặp này không thể dễ dàng suy ra từ khóa công khai hoặc thông tin khác đã biết.
15 hay các thuật toán được công bố Do đó, việc giải mã nếu không dùng được đúng khoá sẽ vô cùng khó, thậm chí không thể thực hiện được.
Khóa đóng vai trò quan trọng trong quá trình mã hóa và giải mã dữ liệu, nhưng không phải lúc nào cũng đáng tin cậy Trong mật mã khóa công khai, người nhận không thể xác định ai là người gửi thông tin, dẫn đến khả năng giả mạo danh tính Đối với mật mã khóa bí mật, việc nhận thông tin không đảm bảo rằng nguồn tin cậy, vì khóa bí mật có thể bị lộ trong quá trình trao đổi Để tăng cường xác thực, "chữ ký số" được giới thiệu như một phương pháp xác nhận tác giả và tính toàn vẹn của văn bản Chữ ký số, là đoạn dữ liệu ngắn được đính kèm với văn bản gốc, được tạo ra bằng cách áp dụng thuật toán băm một chiều để tạo ra giá trị "băm", sau đó mã hóa bằng khóa bí mật của người gửi Khi nhận, văn bản được tách thành hai phần, và giá trị "băm" mới được so sánh với giá trị "băm" cũ phục hồi từ chữ ký số để kiểm tra tính toàn vẹn.
Hình 1.5 Quá trình tạo chữ ký số
Hàm băm không phải là cơ chế mã hóa hay giải mã, mà là công cụ tạo ra mẫu phân tích (digest) cho bản tin Một hàm băm có ba đặc tính chính: tính duy nhất, tính không thể đảo ngược và khả năng xử lý nhanh chóng.
Hàm băm nhận một bản tin với kích thước bất kỳ và tạo ra một đoạn dữ liệu ngắn có độ dài cố định, được gọi là digest hay hash value Khi tính toán hàm băm trên cùng một bản tin, kết quả sẽ luôn cho ra các digest giống nhau.
• Bất cứ một thay đổi nào trong bản tin gốc sẽ ảnh hưởng đến kết quả của digest được tạo ra.
• Không có bất kỳ phương pháp nào có thể tạo ra dữ liệu gốc từ giá trị digest của nó.
Hàm "băm" nhận dữ liệu lớn và tạo ra một chuỗi có chiều dài cố định, được gọi là digest, phản ánh đặc trưng của dữ liệu gốc.
Trong lĩnh vực bảo mật thông tin, các hàm băm phổ biến như MD2, MD4, MD5, SHA-1 và RIPEMD−160 thường được sử dụng Trong quá trình truyền thông, chữ ký số được đính kèm vào bản tin gốc và gửi tới người nhận Khi nhận được toàn bộ bản tin cùng chữ ký số, người nhận sẽ thực hiện các bước kiểm tra để đảm bảo rằng bản tin vẫn nguyên vẹn, không bị sửa đổi và được gửi từ một đối tượng hợp lệ.
• Đối với phần bản tin, người nhận sẽ tạo một digest nhờ sử dụng cùng một hàm băm giống như bên gửi (được thoả thuận trước).
• Đối với phần chữ ký số, người nhận sẽ giải mã nó bằng khoá công khai của người gửi để thu được một digest.
Cuối cùng, người nhận sẽ tiến hành so sánh các digest đã thu được Nếu hai digest này trùng khớp, điều đó chứng tỏ rằng bản tin được gửi từ nguồn hợp pháp và không bị thay đổi trong quá trình truyền tải.
Hình 1.6 Xác thực bản tin bằng chứ ký số
1.3.3 Chứng th c i n t ự đ ệ ử Ở phần trên, chúng ta đã chỉ ra cách sử dụng mật mã khoá công khai để gửi khoá bí mật (session key) dùng cho mã hóa và giải mã nội dung dữ liệu tới người nhận một cách an toàn Tuy nhiên, làm thế nào để có thể đảm bảo rằng một khoá công khai thực sự là của đối tượng gửi hợp lệ ? Cơ chế để thực hiện tính năng xác thực này là nhờ sử dụng các “chứng thực điện tử”
Chứng thực điện tử (Digital Certificates) đóng vai trò tương tự như chứng minh thư hoặc hộ chiếu, được sử dụng để nhận diện các đối tượng tham gia truyền thông trực tuyến như người dùng, máy chủ, thiết bị mạng và ứng dụng Khác với hộ chiếu cần được bảo quản cẩn thận, chứng thực điện tử có thể được sao chép và phân tán tự do trên mạng mà không bị giới hạn.
Chứng thực điện tử là một cấu trúc dữ liệu bao gồm khóa công khai và thông tin chi tiết về chủ sở hữu khóa, được xác nhận tính hợp lệ bởi một bên thứ ba đáng tin cậy, gọi là đơn vị chứng thực chữ ký số (CA - Certificate Authority).
Hình 1.7 Chứng thực điện tử
Các dịch vụ và phạm vi ứng dụng của PKI
Trong phần này, chúng ta sẽ khám phá các yêu cầu cơ bản về an toàn và an ninh thông tin Tiếp theo, chúng ta sẽ xem xét các dịch vụ mà hệ thống PKI cung cấp để đáp ứng những yêu cầu này và đánh giá phạm vi ứng dụng của hệ thống PKI trong thực tiễn.
1.4.1 Các yêu cầu cơ bản c a an toàn an ninh thông tin ủ
An toàn an ninh thông tin là một lĩnh vực đa dạng, trong đó việc sử dụng các phương pháp mã hoá đóng vai trò quan trọng Để đảm bảo an toàn, có bốn yêu cầu cơ bản cần được chú ý.
1) 24T Bí mật thông tin 24T (Confidentiality): Đảm bảo rằng nếu A muốn truyền thông tin cho B thì chỉ có mB ớiđọc được thông tin này.
2) 24T Toàn vẹn dữ liệu ( 24T Integrity) 24T 24T : Thông tin không bị thay đổi bởi những đối tượng không được cấp thẩm quyền.
3) 24T Xác thực đối tượng ( 24T Authentication) 24T 24T : Xác thực đối tượng để các đối tượng truyền tin biết chắc mình đang giao tiếp với đối tượng nào.
4) 24T Không thể chối bỏ ( 24T Non-Repudiaton 24T ) 24T : Các đối tượng không thể chốibỏ những hành động mà mình đã thực hiện.
1.4.2.Khả năng đáp ứng c a các d ch v s d ng PKI ủ ị ụ ử ụ
Phần này sẽ minh hoạ khả năng đảm bảo an toàn an ninh của các dịch vụ sử dụng PKI thông qua ví dụ về chữ ký số Đối với việc bảo vệ tính toàn vẹn dữ liệu, khi một thông điệp được mã hoá và tạo chữ ký số, bất kỳ thay đổi nào đối với chữ ký số sẽ khiến nó không còn khả năng kiểm chứng bởi người nhận.
Nếu đối tượng nhận không thể xác minh chữ ký số do đối tượng truyền tạo ra, điều này cho thấy thông tin được truyền đi đã bị thay đổi hoặc có sai sót.
Để đảm bảo tính không thể chối bỏ, khi một đối tượng tạo chữ ký số cho một thông điệp, chỉ có đối tượng đó mới biết khoá riêng của mình Nếu chữ ký số được xác thực bằng khoá công khai của đối tượng, điều này chứng minh rằng đối tượng đã sử dụng khoá riêng tương ứng để tạo chữ ký Từ đó, tính không thể chối bỏ liên kết các đối tượng với những hành động mà họ đã thực hiện.
Khi đối tượng A muốn xác thực danh tính của đối tượng B, A gửi thông điệp chứa thông tin đến B B mã hóa thông điệp bằng khóa riêng của mình và gửi kết quả trở lại cho A A kiểm tra bằng cách giải mã thông điệp nhận được bằng khóa công khai của B Nếu thông điệp được xác minh, A có thể chắc chắn rằng mình đang liên lạc với B.
Để đảm bảo tính bí mật của thông tin, A mã hóa dữ liệu cần trao đổi với B bằng khóa công khai của B trước khi thực hiện việc truyền tải.
23 cho B Khoá bí mật được giữ an toàn nên chỉ B mới có thể giải mã và đọc được thông tin.
1.4.3 Các ứng dụng bảo mật dựa trên hệ thống PKI
Các ứng dụng và công nghệ có thể dẫn đến yêu cầu triển khai PKI bao gồm:
• Xác thực dựa trên giao thức 802.1x Việc xác thực được áp dụng cho người dùng hoặc máy tính đang truy cập tới mạng vô tuyến 802.11.
Chữ ký số đảm bảo an toàn cho các giao dịch trực tuyến thông qua cơ chế xác minh danh tính người gửi và bảo vệ tính toàn vẹn của dữ liệu Bên cạnh đó, chữ ký số còn cung cấp tính năng "không thể chối bỏ", giúp khẳng định trách nhiệm của người gửi trong mọi giao dịch.
Hệ thống mã hoá file (EFS) sử dụng kết hợp giữa mã hoá đối xứng và mã hoá bất đối xứng để bảo vệ dữ liệu EFS cung cấp hai phương thức khôi phục: khôi phục dữ liệu cho phép mở toàn bộ file đã mã hoá, và khôi phục khoá giúp phục hồi khoá bí mật từ cơ sở dữ liệu của CA.
Xác thực và mã hoá giao dịch Web thông qua chứng thực SSL giúp máy khách xác minh định danh của máy chủ, đồng thời mã hoá dữ liệu trao đổi giữa hai bên Chứng thực SSL cũng có thể được phân phối tới máy khách, cho phép họ xác thực với máy chủ Kỹ thuật này hỗ trợ xác thực lẫn nhau giữa máy chủ và máy khách trong môi trường Web.
Bảo mật IP (IPSec) sử dụng các chứng thực để xác thực hai điểm đầu cuối, cho phép mã hóa và ký số toàn bộ thông tin giữa chúng Khi được xác thực, IPSec đảm bảo an toàn cho dữ liệu truyền tải giữa các điểm đầu cuối.
24 chứng thực không đóng vai trò thực sự trong mã hoá và ký dữ liệu IPSec, chúng chỉ được dùng đề xác thực 2 điểm đầu cuối.
Hình 1.8 Các ứng dụng dựa trên PKI
Thư điện tử bảo mật là một kỹ thuật quan trọng giúp đảm bảo tính tin cậy, toàn vẹn dữ liệu và không thể chối bỏ cho các thông điệp điện tử Để nâng cao mức độ bảo mật, chúng ta có thể sử dụng các chứng thực nhằm xác minh danh tính của người gửi, nguồn gốc của thông điệp và tính xác thực của nội dung.
Đăng nhập vào hệ thống bằng thẻ thông minh giúp tăng cường bảo mật thông tin nhờ vào cơ chế xác thực hai yếu tố Để thực hiện xác thực, người dùng cần sở hữu thẻ thông minh và nhập đúng mã PIN (Số nhận dạng cá nhân) của thẻ đó.
Đăng nhập một lần (Single sign-on) giúp người sử dụng giảm bớt số mật khẩu cần nhớ bằng cách cho phép xác thực chỉ một lần cho nhiều ứng dụng Thay vì phải xác thực riêng lẻ cho từng ứng dụng, người dùng chỉ cần xác thực tại một nơi lưu trữ thông tin xác thực của PKI, như thẻ thông minh Phần mềm xác thực Client trên máy tính sẽ tự động xử lý các yêu cầu xác thực một cách mượt mà và cung cấp thông tin xác thực cho từng ứng dụng.
Ký mã phần mềm là một kỹ thuật quan trọng nhằm bảo vệ máy tính khỏi việc cài đặt các phần mềm không được xác nhận như trình điều khiển thiết bị và các ứng dụng ký sinh Khi nội dung đã được ký, các ứng dụng hỗ trợ ký mã, chẳng hạn như trình duyệt Web của Microsoft, có khả năng ngăn chặn truy cập tới các điều kiểm chưa được ký, từ đó nâng cao mức độ an toàn cho người dùng.
CÁC MÔ HÌNH TRIỂ N KHAI H Ệ TH Ố NG PKI
Kiến trúc CA đơn nhất
Trong kiến trúc CA đơn nhất, chỉ có một Chứng thực viên (CA) duy nhất phát hành và phân phối các chứng thực cùng với danh sách thu hồi chứng thực (CRL) đến các thực thể Tất cả các thực thể trong hệ thống đều phụ thuộc vào CA này và chỉ sử dụng các chứng thực do CA đó cấp Do chỉ có một CA, không tồn tại mối quan hệ tin cậy giữa các CA khác trong kiến trúc này, và cũng không cho phép thêm bất kỳ CA mới nào vào hệ thống PKI.
Hình 2.1 Kiến trúc CA đơn nhất
Trong kiến trúc này, tất cả các thực thể được kết nối trong một môi trường tin cậy nhờ vào một điểm tin cậy chung là CA, được sử dụng cho tất cả các thực thể Chẳng hạn, khi Alice và Bob đã tin cậy CA1, họ sẽ xác minh và công nhận tính hợp lệ của các chứng thực từ nhau thông qua CA1, từ đó tiến hành trao đổi thông tin Hình 2.1 minh họa kiến trúc CA đơn nhất.
2.1.1 Ưu điểm của kiến trúc CA đơn nhất
• Thực hiện triển khai rất đơn giản vì chỉ cần thiết lập một CA.
Kiến trúc CA đơn nhất là lựa chọn lý tưởng cho các tổ chức nhỏ, nơi số lượng người sử dụng ít và phạm vi hoạt động không rộng lớn.
2.1.2 Nhược điểm của kiến trúc CA đơn nhất
• Kiến trúc CA đơn nhất thể hiện một điểm lỗi đơn lẻ Nếu khoá bí mật của
CA bị lộ thì toàn bộ các chứng thực được phát hành bởi nó sẽ bị vô hiệu hoá và hệ thống PKI trở nên mất tác dụng
Kiến trúc CA đơn nhất có hạn chế về khả năng mở rộng, đặc biệt khi tổ chức phát triển và hợp tác với bên ngoài Kiến trúc này không cho phép thêm CA mới vào hệ thống, dẫn đến hiệu quả kém Để khắc phục vấn đề này, mô hình danh sách tin cậy đã được phát triển như một cải tiến cho kiến trúc CA đơn nhất.
Kiến trúc danh sách tin cậy
Trong mô hình danh sách tin cậy, dịch vụ PKI được cung cấp bởi nhiều CA mà không thiết lập mối quan hệ tin cậy lẫn nhau Các thực thể cần duy trì danh sách các CA được tin cậy và chỉ sử dụng các CA này cho các giao dịch an toàn.
Đã có 28 chứng thực và CRL được phát hành bởi các CA trong danh sách, thể hiện kiến trúc phổ biến cho dịch vụ Web Trong mô hình này, các trình duyệt lưu trữ một file riêng biệt chứa các chứng thực điện tử gốc.
CA là một công cụ đáng tin cậy, tồn tại ngay khi trình duyệt được cài đặt Người dùng có thể quản lý file này một cách dễ dàng, cho phép thêm hoặc xóa các chứng thực điện tử trong danh sách.
Trình duyệt Web sử dụng các cặp khóa công khai và khóa riêng để thực hiện ký, kiểm chứng, giải mã và mã hóa thư điện tử theo chuẩn S/MIME Ngoài ra, với chứng thực điện tử, trình duyệt còn có khả năng thiết lập các phiên truyền thông an toàn thông qua SSL.
Hình 2.2 Kiến trúc PKI danh sách tin cậy
Theo kiến trúc danh sách tin cậy, để hai đối tượng trao đổi thông tin bí mật, mỗi đối tượng phải thuộc về một CA khác nhau Ví dụ, khi Alice muốn giao tiếp với Bob, cả hai đều tin cậy các CA khác nhau: Alice tin cậy CA−1, trong khi Bob tin cậy CA−2 Để Alice có thể tin tưởng Bob, cô cần nhận được chứng thực từ CA của Bob Hình 2.3 minh họa quá trình này.
2.2.1 Ưu điểm của kiến trúc PKI danh sách tin cậy
Mô hình danh sách tin cậy nổi bật với thiết kế đơn giản, giúp quá trình truyền thông và xác nhận diễn ra theo một hướng duy nhất, từ đó dễ dàng triển khai.
Trong kiến trúc này, người dùng có quyền quản lý toàn bộ tệp lưu trữ danh sách chứng thực điện tử của các chứng nhận viên (CA) mà họ tin tưởng.
Kiến trúc này hoạt động hiệu quả với giao thức quản lý trạng thái chứng thực điện tử trực tiếp nhờ vào các nhánh xác thực đơn giản Ngoài ra, yêu cầu về trạng thái chứng thực điện tử chỉ được gửi đến các CA nằm trong danh sách CA đáng tin cậy.
2.2.2 Nhược điểm của kiến trúc PKI danh sách tin cậy
Người dùng có quyền sửa đổi nội dung của file chứa chứng thực điện tử từ các CA mà họ tin cậy, dẫn đến việc quản lý danh sách CA được tin cậy của tổ chức trở nên khó khăn.
Việc khởi tạo danh sách mặc định các Chứng chỉ Ủy quyền (CA) đáng tin cậy khi cài đặt trình duyệt có thể gây khó khăn trong việc đảm bảo tính xác thực trong quá trình khởi động.
30 tạo thông tin về khoá công khai của các CA này Đây có thể là một kẽ hở để các đối tượng tấn công lợi dụng.
Các cặp chứng thực điện tử ngang hàng (xác thực chéo) không nhận được sự hỗ trợ trực tiếp, dẫn đến việc hạn chế khả năng của các cơ quan chứng thực (CA) trong việc quản lý độ tin cậy của mình đối với các CA khác.
• Hiện tại các trình duyệt không hề hỗ trợ tính năng tự động lấy thông tin trạng thái hoặc huỷ bỏ các chứng thực điện tử.
Khi số lượng các chứng thực viên (CA) được tin cậy bởi một thực thể tăng lên, danh sách tin cậy cũng trở nên phức tạp hơn Nếu khoá bí mật của một CA bị lộ, CA này không thể thông báo cho tất cả các thực thể đã tin tưởng vào nó về tình trạng lộ khoá, do thiếu sự nhận biết của CA đối với các thực thể đó.
Kiến trúc PKI phân cấp
Kiến trúc PKI phân cấp là mô hình phổ biến nhất được các tổ chức áp dụng Trong mô hình này, dịch vụ PKI được cung cấp bởi nhiều CA khác nhau, tạo ra một hệ thống an toàn và tin cậy.
CA trong kiến trúc PKI phân cấp chia sẻ một quan hệ tin cậy giữa chúng Các
Trong kiến trúc PKI phân cấp, các CA được kết nối thông qua mối quan hệ cấp trên và cấp dưới CA gốc đóng vai trò là điểm tin cậy duy nhất trong hệ thống, chịu trách nhiệm cấp chứng thực điện tử cho các CA thứ cấp.
31 cấp hoặc các EE Đến lượt các CA này lại cấp các chứng thực điện tử cho những CA ở mức thấp hơn hoặc cho các EE.
Hình 2.4 Kiến trúc PKI phân cấp
Khi CA gốc bổ nhiệm một CA cấp dưới, CA gốc phát hành chứng thực để chỉ định các hoạt động của CA cấp dưới Mô hình này yêu cầu tất cả đối tượng phải tin cậy vào CA gốc và biết khoá công khai của nó Sự tin cậy được xây dựng theo các cấp từ CA gốc đến các CA thứ cấp và người sử dụng Tất cả chứng thực điện tử có thể được kiểm chứng thông qua đường dẫn chứng thực đến CA gốc.
Trong kiến trúc PKI phân cấp, đường dẫn chứng thực bắt đầu từ CA gốc và kết thúc tại thực thể cuối cùng Quá trình hình thành đường dẫn chứng thực khởi đầu với việc chứng thực của thực thể cuối cùng, bao gồm hai phần mở rộng nhận dạng để xác định chính xác chứng thực của CA.
Phần mở rộng Issuer Identifier giúp xác định chứng thực CA trong kho lưu trữ bằng cách so sánh giá trị của nó với giá trị Subject Identifier trong chứng thực CA.
• Authority key identifier: Phần mở rộng này nhận dạng khoá được sử dụng để ký chứng thực.
Hình 2.5 Đường dẫn chứng thực trong kiến trúc PKI phân cấp
Mỗi thực thể chỉ có một đường dẫn chứng thực duy nhất, như được minh họa trong hình 2.5 Ví dụ, đường dẫn chứng thực của Alice được thể hiện rõ ràng.
• [Root CA−3]: [CA−3 CA−2]: [CA−2 CA−1]: [CA−1 Alice] Đường dẫn chứng thực của Bob:
• [Root CA−3]: [CA−3 CA−2]: [CA−2 CA−1]: [CA−1 Bob] Đường dẫn chứng thực của James:
2.3.1 Ưu điểm của kiến trúc PKI phân cấp
Cấu trúc hệ thống quản lý của hầu hết các tổ chức thường mang hình thức phân cấp, trong đó các mối quan hệ giữa các thành viên tương tự như các mối quan hệ trong mô hình phân cấp.
33 trong các tổ chức Vì vậy, ta có thể coi các nhánh của quá trình xác nhận đối tượng phản ánhcác nhánh trong cấu trúc của tổ chức.
Để tìm ra một nhánh xác nhận, cần phải đi theo một hướng nhất định và tránh hiện tượng vòng lặp Nhờ đó, quá trình xác nhận trở nên đơn giản và nhanh chóng.
Tất cả các đối tượng sử dụng đều có nhánh xác nhận liên kết với CA gốc Do đó, nếu một đối tượng A cung cấp thông tin về nhánh xác nhận của mình cho B, thì B cũng có khả năng xác nhận theo hướng đó vì B đã biết khóa công khai của CA gốc.
Kiến trúc PKI phân cấp hoàn toàn có khả năng mở rộng, cho phép dễ dàng đáp ứng nhu cầu tăng trưởng của tổ chức Để thêm một thực thể mới vào hệ thống PKI, CA gốc chỉ cần thiết lập một quan hệ tin cậy với CA cấp thấp của thực thể đó.
Hình 2.6 Đưa thêm một CA mới vào mức dưới CA gốc
Hình 2.7 Đưa thêm một CA mới vào mức dưới một CA cấp cao
• Dễ triển khai: Do tính chất một hướng “uni−directional”, kiến trúc PKI phân cấp hoàn toàn có thể triển khai đơn giản Đường dẫn từ thực thể tới
CA phát hành chứng thực có thể được xác định nhanh chóng và dễ dàng.
Đường dẫn chứng thực ngắn trong kiến trúc PKI là một cấu trúc liên kết, trong đó đường dẫn lớn nhất tương đương với chứng thực của CA cho từng CA cấp thấp, cùng với chứng thực của thực thể cuối cùng.
2.3.2.Khuyết điểm của kiến trúc PKI phân cấp
• Trên một phạm vi lớn, không thể chỉ có một CA duy nhất để đảm nhận tất cả các quá trình xác nhận.
• Các quan hệ kinh doanh, thương mại không phải lúc nào cũng có dạng phân cấp.
Khi khóa riêng của Chứng chỉ số (CA) gốc bị lộ, toàn bộ hệ thống sẽ gặp nguy hiểm Để khắc phục, cần thay cặp khóa mới, đồng thời thông tin về khóa công
2.4 Kiến trúc PKI mạng lưới
Trong kiến trúc này, việc xác thực ngang hàng giữa các CA tạo ra một mạng lưới tin cậy lẫn nhau Các thực thể có thể truy cập khoá công khai của CA gần nhất, thường là CA cấp chứng thực điện tử cho chúng Để kiểm tra chứng thực điện tử, các đối tượng cần xác minh quá trình xác nhận với CA đã phát hành chứng thực đó.
Trong mô hình PKI mạng lưới, các CA cần thực hiện xác minh chéo để thiết lập mối quan hệ tin cậy lẫn nhau Quá trình này cho phép hai CA xác nhận và hỗ trợ giao tiếp bảo mật giữa các thực thể tương ứng của chúng Việc phát hành chứng chỉ cho nhau là cách thức mà các CA thực hiện xác nhận ngang hàng, đảm bảo an toàn cho các giao dịch trực tuyến.
35 những chứng thực điện tử, những cặp chứng thực điện tử này được kết hợp và lưu trong một cấu trúc dữ liệu có tên 24T CrossCertificatePair 24T
Hình 2.8 Kiến trúc PKI mạng lưới
Kiến trúc PKI lai ghép
Nhiều tổ chức thường phải hợp tác với các đơn vị khác để quản lý hiệu quả các hoạt động kinh doanh của mình Kiến trúc PKI (Public Key Infrastructure) đóng vai trò quan trọng trong việc đảm bảo an toàn và bảo mật thông tin trong quá trình hợp tác này.
Các tổ chức có thể có kiến trúc PKI khác nhau, chẳng hạn như PKI phân cấp hoặc PKI mạng lưới Để đảm bảo sự hợp tác trong môi trường tin cậy, PKI cần cung cấp giải pháp tối ưu Kiến trúc PKI lai ghép cho phép các tổ chức với các kiến trúc khác nhau phối hợp hoạt động hiệu quả.
Phần tiếp theo sẽ phân tích một kiến trúc PKI lai ghép tổng quát, bao gồm kiến trúc CA đơn nhất, phân cấp và mắt lưới Trong đó, công ty AllSolv áp dụng kiến trúc CA đơn nhất (PKI1), công ty WebEyes sử dụng kiến trúc PKI phân cấp (PKI2), và công ty SureSolv triển khai kiến trúc mắt lưới (PKI3) Mỗi tổ chức đều có các CA cấp thấp phù hợp với nhu cầu của họ và các thực thể đầu cuối, như được minh họa trong hình 2.10.
Hình 2.10 Kiến trúc PKI lai ghép
Alice và Bob thuộc PKI1, James và Charlie là thành viên của PKI2, trong khi Smith và Robert là thành viên của PKI3 Tất cả các thành viên này đã nhận chứng thực từ các CA tương ứng của họ.
3 kiểu kiến trúc PKI lai ghép, gồm:
• Kiến trúc danh sách tin cậy mở rộng (Extended Trust List architecture):
Mở rộng mô hình danh sách tin cậy để hỗ trợ các đường dẫn chứng thực có độ dài lớn hơn 1.
• Kiến trúc PKI xác minh chéo (Cross−certified PKI architecture): Thiết lập quan hệ ngang hàng để cho phép truyền thông bảo mật.
• Kiến trúc CA cầu nối (Bridge CA architecture): Kiến trúc này hỗ trợ nhiều kiến trúc PKI.
2.5.1 Kiến trúc danh sách mở ộng r
Trong kiến trúc danh sách tin cậy mở rộng, các thực thể đầu cuối duy trì một danh sách nhiều điểm tin cậy, mỗi điểm gắn liền với một kiến trúc PKI như CA đơn nhất, phân cấp hoặc PKI mắt lưới Ví dụ, Alice nhận chứng thực từ CA-1 và để giao tiếp với James, Charlie, Smith, và Robert, cô phải tin cậy vào PKI2 và PKI3 Alice có thể chọn bất kỳ CA nào trong PKI2 hoặc PKI3, hoặc đưa toàn bộ tổ chức vào danh sách tin cậy của mình, như thể hiện trong danh sách tin cậy mở rộng của cô.
Như chỉ ra trên hình 2.11, Alice tin cậy các CA là A1, B1, và C1, và do đó Alice đưa chúng vào danh sách tin cậy mở rộng của cô ta
2.5.2.Kiến trúc PKI xác minh chéo
Trong kiến trúc xác minh chéo, một CA gốc hoặc CA cấp thấp trong hệ thống PKI thiết lập mối quan hệ tin cậy ngang hàng với các CA khác.
CA gốc hoặc các CA cấp thấp trong hệ thống PKI khác thiết lập mối quan hệ tin cậy ngang hàng Ví dụ, CA gốc của công ty AllSolv tạo mối quan hệ tin cậy với hai hệ thống PKI khác, PKI2 và PKI3 Tương tự, CA gốc của PKI2 cũng thiết lập quan hệ tin cậy với CA gốc của PKI1 và PKI3 Mỗi người dùng sẽ có một điểm tin cậy riêng, và quan hệ chéo giữa các doanh nghiệp diễn ra theo kiểu peer-to-peer Khi các CA xác minh chéo lẫn nhau, các thực thể có thể xác minh các thực thể trong hệ thống PKI khác Trong kiến trúc danh sách tin cậy mở rộng, Alice và Robert cần cập nhật danh sách tin cậy của riêng họ, điều này rất phù hợp cho một số lượng nhỏ hệ thống PKI doanh nghiệp cần thiết lập quan hệ tin cậy.
Theo như hình 2.12, ta thấy 3 quan hệ ngang hàng cần được thiết lập, và để thiết lập các quan hệ này thì cần có 6 chứng thực.
Trong kiến trúc PKI, người dùng xây dựng các đường dẫn chứng thực khác nhau cho cùng một thực thể Đường dẫn chứng thực bắt đầu từ điểm tin cậy trong PKI nguyên bản Ví dụ, nếu Alice thuộc PKI phân cấp, đường dẫn sẽ bắt đầu từ CA gốc; còn nếu Alice thuộc PKI mắt lưới, đường dẫn sẽ bắt đầu từ CA phát hành chứng thực của cô Chứng thực chéo có thể kết nối tới CA gốc của kiến trúc phân cấp, trong khi chứng thực chéo khác có thể liên kết tới một CA trong kiến trúc.
Trong kiến trúc PKI mắt lưới, việc xác minh chéo sử dụng phương pháp hình thành đường dẫn chứng thực tường minh trong hệ thống phân cấp Đường dẫn này kết thúc tại các điểm đầu cuối khi tới một gốc bên ngoài Quá trình hình thành đường dẫn chứng thực trở nên phức tạp hơn, yêu cầu sử dụng kiến trúc PKI mắt lưới để nhận dạng một hoặc nhiều chứng thực chéo nhằm đạt được điểm tin cậy Ví dụ về đường dẫn chứng thực được minh họa trong hình 2.13.
Hình 2.12 Kiến trúc PKI xác minh chéo Đường dẫn chứng thực được xây dựng bởi Alice cho Bob:
Các đường dẫn chứng thực được xây dựng bởi Alice cho James:
• [CA−1 CA−2]: [CA−2 CA−4]: [CA−4 James]
• [CA−1 CA−3]: [CA−3 CA−2]: [CA−2 CA−4]: [CA−4 James]
Hình 2.13 Đường dẫn chứng thực trong kiế n trúc PKI xác minh chéo
2.5.3 Kiến trúc CA cầu nối
Kiến trúc CA cầu nối là giải pháp lý tưởng để kết nối các hệ thống PKI khác nhau Thay vì phát hành chứng thực trực tiếp cho người dùng, CA cầu nối thiết lập quan hệ tin cậy ngang hàng với các CA của các thực thể khác Những quan hệ này tạo thành một cầu nối tin cậy, cho phép các thực thể tương tác hiệu quả với nhau.
Sự thiết lập quan hệ tin cậy trong kiến trúc CA cầu nối phụ thuộc vào kiểu kiến trúc PKI Trong kiến trúc PKI phân cấp, sự tin cậy được xây dựng dựa trên CA gốc, trong khi đó, kiến trúc PKI mắt lưới cho phép thiết lập quan hệ tin cậy với bất kỳ thành phần nào trong mạng lưới.
CA nào trong hệ thống PKI.
CA thiết lập mối quan hệ tin cậy với CA cầu nối, được gọi là CA chính Quan hệ này mang tính chất ngang hàng (Peer-To-Peer) giữa CA chính và CA cầu nối Việc tích hợp thêm CA mới hoặc toàn bộ hệ thống PKI doanh nghiệp vào PKI cầu nối diễn ra một cách đơn giản và hiệu quả.
Trong bài viết này, chúng ta khám phá sự trong suốt của 43 đối với người sử dụng, đồng thời khẳng định rằng không có sự thay đổi nào xảy ra đối với các điểm tin cậy Hình 2.14 minh họa cách CA cầu nối được áp dụng để thiết lập mối quan hệ tin cậy giữa kiến trúc CA đơn nhất với PKI mắt lưới và PKI phân cấp Cụ thể, Alice nhận chứng thực từ một CA trong PKI phân cấp và sử dụng CA gốc của hệ thống này làm điểm tin cậy, trong khi James nhận chứng thực từ một CA trong PKI mắt lưới.
Alice và James có thể thiết lập một mối quan hệ tin cậy thông qua cầu nối đáng tin cậy, cho phép họ tương tác một cách hiệu quả và an toàn.
Trong kiến trúc CA cầu nối, nếu CA chính bị tổn hại, CA cầu nối sẽ hủy bỏ chứng thực của nó, bảo vệ các quan hệ tin cậy khác Ngược lại, nếu CA cầu nối bị tổn hại, CA chính sẽ hủy bỏ chứng thực đã phát hành cho CA cầu nối đó.
Các giao thức quản lý PKI
Giao thức quản lý PKI cho phép các Tổ chức cấp chứng thực (CA) thu thập thông tin cần thiết để phát hành và hủy bỏ chứng thực Những giao thức PKI phổ biến bao gồm PKCS#10, PKCS#7, CMP, CMC và SCEP.
PKCS#10 là chuẩn về cú pháp yêu cầu chứng thực (Certificate Request Syntax Standard) Theo chuẩn PKCS#10, một yêu cầu chứng thực bao gồm 3 thành phần sau:
• Thông tin yêu cầu chứng thực.
• Nhận dạng của thuật toán dùng cho chữ ký số.
• Chữ ký số trên thông tin yêu cầu chứng thực.
Thông tin yêu cầu chứng thực bao gồm tên phân biệt duy nhất của thực thể (DN - Distinguished Name), khoá công khai, và một số thuộc tính tuỳ chọn khác Các thuộc tính này cung cấp thông tin bổ sung như địa chỉ bưu điện để phản hồi khi cần, cũng như mật khẩu kiểm tra (challenge password) cho việc yêu cầu huỷ bỏ chứng thực sau này.
Distinguished Name Public Keys Optional Atributes Algorithm Identifier Digital Signature
Hình 3.1 Khuôn dạng yêu cầu chứng thực sử dụng PKCS#10
Trong quá trình yêu cầu cấp phát chứng thực, Bob muốn nhận chứng thực từ CA của công ty AllSolv bằng cách sử dụng chuẩn PKCS#10 Để thực hiện yêu cầu này, Bob cần tuân theo một số bước cụ thể để đảm bảo việc cấp phát chứng thực diễn ra thuận lợi.
1) Tạo giá trị CertificateRequestInfo theo chuẩn PKCS#10 bằng khoá công khai và tên người dùng của anh ta Giá trị CertificateRequestInfo bao gồm tên phân biệt duy nhất (DN) của thực thể (trong trường hợp này là Bob) và khoá công khai của thực thể đó.
2) Sau khi tạo được giá trị CertificateRequestInfo, Bob cần ký xác nhận vào giá trị này bằng khoá bí mật của anh ta.
3) Cuối cùng, Bob cần tạo giá trị CertifcateRequest theo chuẩn PKCS#10 từ giá trị CertificateRequestInfo và chữ ký của anh ta.
Các bước trên được giải thích cụ thể như sau:
Bob tạo giá trị CertificateRequestInfo bằng cách sử dụng tên thông thường của mình và khoá công khai, với thông tin rằng anh làm việc cho công ty AllSolv tại Mỹ Giá trị này sau đó sẽ được mã hoá để tạo ra một chuỗi byte như mô tả dưới đây.
CertificateRequestInfo gồm các thành phần sau:
• Version: Thể hiện phiên bản để có thể tương thích với bất cứ thay đổi nào trong tương lai Ở ví dụ trên, giá trị phiên bản là 0.
• Subject: Thể hiện tên phân biệt duy nhất DN (Distinguished Name) của chủ thể yêu cầu chứng thực.
• SubjectPublicKeyInfo: Thể hiện thông tin về khoá công khai của chủ thể yêu cầu chứng thực
• Attributes: Thể hiện thông tin bổ sung về chủ thể yêu cầu chứng thực, chẳng hạn tên thông thường và tên tổ chức.
Sau khi tạo ra giá trị CertificateRequestInfo, Bob cần ký xác nhận vào giá trị đó.
Bob cần sử dụng khoá bí mật của mình để ký xác nhận cho CertificateRequestInfo sau khi giá trị này được tạo ra Quá trình ký xác nhận giá trị CertificateRequestInfo bao gồm ba bước.
1) Một digest tạo ra bằng MD5 được đưa vào mã CertificateInfo (encoded DigestInfo)
2) Một giá trị DigestInfo được mã hoá (encode) từ “message digest” và giá trị CertificateInfo ở trên.
3) Sau cùng, giá trị mã DigestInfo này được chuyển thành mật mã nhờ sử dụng khoá bí mật của Bob Quá trình tạo mật mã giá trị DigestInfo cho một chuỗi byte (octet) gọi là chữ ký số Chữ ký này có dạng sau:
Sau khi ký xác nhận giá trị CertificateRequestInfo, Bob cần tạo một giá trị cho trường CertificateRequest.
Tạo giá trị cho trường CertificateRequest: CertificateRequestInfo và chữ ký được sử dụng để tạo CertificateRequest theo chuẩn PKCS#10 Nội dung này sẽ được gửi tới CA để yêu cầu cấp phát chứng thực CertificateRequest có dạng như sau:
CertificateRequest gồm các thành phần:
1) CertificationRequestInfo: thể hiện giá trị thông tin yêu cầu chứng thực đang được ký xác nhận.
2) SignatureAlgorithm: Thể hiện thuật toán được được dùng để ký thông tin yêu cầu chứng thực.
3) Signature: Là kết quả mã hoá (encoding) giá trị CertificateRequestInfo với khoá bí mật của chủ thể.
Sau khi Bob tạo CertificateRequest, anh gửi yêu cầu này tới CA để xin cấp chứng thực CA sẽ xác thực Bob bằng cách kiểm tra chữ ký và thông tin trong CertificateRequest, sau đó phát hành chứng thực cho Bob.
PKCS#10 không hỗ trợ giao thức HTTP, nhưng thường được sử dụng với SSL để thực hiện các yêu cầu chứng thực qua Web Trong giao dịch có 3 đối tác, một RA xác thực yêu cầu sau khi một thực thể đã chuyển nó tới CA Quá trình này diễn ra khi PKCS#10 kết hợp với SSL để đảm bảo tính bảo mật và xác thực trong giao dịch.
1) Một kết nối SSL được thiết lập giữa khách thể (client) và CA.
2) Khách thể chuyển yêu cầu theo chuẩn PKCS#10 tới CA.
3) CA gửi yêu cầu nhận được tới RA để xác minh tính hợp lệ.
4) Một phiên SSL được thiết lập giữa RA và CA.
5) Căn cứ vào kết quả xác minh thông tin, RA sẽ xử lý yêu cầu được chuyển tới RA có thể chấp nhận hoặc từ chối yêu cầu.
6) Nếu RA chấp nhận yêu cầu cấp phát chứng thực thì CA sẽ phát hành một chứng thực cho đối tượng đã yêu cầu.
Các hạn chế của PKCS#10: Mặc dù PKCS#10 là chuẩn định dạng được sử dụng rộng rãi nhưng cũng có một số các hạn chế của nó
PKCS#10 không thể tách rời khỏi thuật toán mã hóa, ví dụ như với thuật toán RSA, PKCS#10 giả định rằng khóa bí mật có thể được sử dụng để tạo ra chữ ký số.
Chữ ký số theo chuẩn PKCS#10 không cung cấp đầy đủ thông tin cần thiết cho CA để xác thực người sử dụng Hơn nữa, thiếu một cơ chế rõ ràng để đảm bảo rằng yêu cầu chứng thực không bị thay đổi trong quá trình truyền tải dữ liệu.
PKCS#10 định nghĩa cú pháp cho yêu cầu chứng thực nhưng không quy định cú pháp và giao thức cho các loại bản tin khác, như yêu cầu huỷ bỏ chứng thực Do đó, các thông điệp không phải là yêu cầu chứng thực cần được thực hiện qua các giao thức khác.
PKCS#7, hay chuẩn cú pháp cho bản tin mật mã, định nghĩa cú pháp cho dữ liệu mật mã như chữ ký số Chuẩn này không chỉ cho phép xác thực nội dung của bản tin mà còn xác thực thông tin thuộc tính Một số ứng dụng quan trọng của PKCS#7 bao gồm việc bảo mật thông tin và xác thực danh tính trong các giao dịch điện tử.
• CA sử dụng PKCS#7 làm bản tin trả lời tới đối tượng yêu cầu chứng thực.
• PKCS#7 được sử dụng để xác thực các bản tin chứng thực được gửi tới một thực thể.
• PKCS#7 cung cấp toàn bộ thông tin tới CA để xử lý yêu cầu chứng thực.
• PKCS#7 được sử dụng bởi nhiều giao thức chẳng hạn S/MIME để cung cấp tính năng bảo mật.
PKCS#7 quy định rằng khuôn dạng của bản tin phải gồm 2 trường: Kiểu nội dung (Content type) và nội dung
Kiểu nội dung: Trường “content type” chỉ ra chuẩn cho định dạng của nội dung và được xem như một định dạng đối tượng (OID - object identifier)
Có 6 kiểu nội dung được định nghĩa bởi PKCS#7 là:
• Signed data (dữ liệu đã ký).
• Enveloped data (dữ liệu được đóng gói)
• Signed and enveloped data (dữ liệu được đóng gói và được ký).
• Digested data (dữ liệu đã được “băm”).
• Encrypted data (dữ liệu được mật mã).
Các kiểu nội dung cũng được phân loại thành 2 lớp:
Lớp cơ bản (Base) chứa kiểu nội dung dữ liệu không mật mã, gọi là non−cryptographic data Tất cả các loại dữ liệu không được mã hóa đều được bao gồm trong lớp này.
• Lớp mở rộng (Enhanced): Gồm các kiểu nội dung khác so với kiểu nội dung dữ liệu của lớp cơ sở.
Phần tiếp theo sẽ bàn đến kiểu nội dunng dữ liệu đã được ký (signed data) vì nó hầu như được sử dụng nhiều trong mật mã PKI.
Dữ liệu đã được ký (signed data): Các trường được chứa trong kiểu dữ liệu đã được ký gồm:
• Version: Nó là số phiên bản của nội dung.
• Digest algorithms: Đây là các thuật toán mã hoá message digest của nội dung (encrypted message digest algorithms)
• Content Info: Đây là nội dung được ký số.
• Certificates: Trường tuỳ chọn này là tập hợp các chứng thực theo chuẩn X.509 và/hoặc PKCS#6.
• CRLs: Trường tuỳ chọn này chứa một tập các CRL.
• Signer Info: Trường này gồm các thông tin sau:
□ Phiên bản của chứng thực.
□ Tổ chức phát hành và một số thứ tự.
□ Các thuộc tính dùng để nhận thực.
□ Thuật toán chữ ký số.
□ Các thuộc tính không dùng để nhận thực.
Các bước sau đây được thực hiện để tạo ra kiểu nội dung dữ liệu đã được ký (signed data content type):
1) Một “message digest”cho mỗi người sử dụng được tính toán dựa trên thuật toán tạo “message digest” của người ký
Họ các chuẩn X
The International Telecommunication Union (ITU) and the International Standards Organization (ISO) have proposed several standards to define protocols, information, and authentication processes These are commonly referred to as a set of standards.
X Hai chuẩn được sử dụng rộng rãi nhất là X.500 và X.509 Chuẩn X.500 áp dụng cho việc thiết kế thư mục công khai, trực tuyến và phân tán cho mạng chia sẻ chung Chuẩn X.509 là nền tảng cho x ácthực, được thiết kế để hỗ trợ dịch vụ thư mục dùng chung X.500 Ngoài ra, các chuẩn này cũng được sử dụng để đảm bảo sự tương thích giữa các sản phẩm từ nhiều hãng khác nhau cung cấp dịch vụ PKI và đồng thời chúng cũng là các chuẩn quốc tế quan trọng cho PKI.
Thư mục X.500 là nơi lưu trữ các chứng thực và danh sách thu hồi chứng thực (CRL) do CA phát hành, hoạt động như một dịch vụ thư mục chia sẻ phân tán Thông tin trong một tổ chức có thể được lưu trữ nội bộ trong nhiều cơ sở dữ liệu gọi là DSA (Directory Service Agents), không giới hạn cho một tổ chức cụ thể Một DSA có thể chứa thông tin về nhiều tổ chức, và ngược lại, thông tin của một tổ chức lớn có thể được phân bổ trong nhiều DSA Cơ sở dữ liệu DSA được duy trì theo kiến trúc mô hình thông tin X.500, cho phép trao đổi thông tin giữa các DSA thông qua cây thông tin thư mục (DIT - Directory Information Tree) DIT được tổ chức theo cấu trúc cây, với gốc là thực thể cao nhất, tiếp theo là các quốc gia và tổ chức, trong đó mỗi tổ chức bao gồm các cá nhân hoặc đơn vị thành viên Mỗi DSA chứa một phần cơ sở dữ liệu liên quan đến các thực thể của nó, nhưng có thể tìm kiếm thông tin từ các DSA khác thông qua DIT Chuẩn X.500 quy định cách thức liên kết các DSA để tạo ra một bố trí thông tin chia sẻ chung.
Các tổ chức có khả năng xác định cấu trúc DIT riêng, bao gồm các thuộc tính và lớp đối tượng đặc trưng cho mình Điều này đảm bảo rằng các thuộc tính chỉ thuộc về tổ chức đã định nghĩa Lớp đối tượng, thuộc tính và DIT đều tuân theo tiêu chuẩn X.500, tạo ra một cơ sở hạ tầng hiệu quả để cung cấp thông tin nội bộ cho tổ chức.
Theo chuẩn X.500, thông tin được lưu trữ dưới dạng các đầu mục (entry) trong thư mục, với mỗi đầu mục thuộc về một lớp đối tượng như quốc gia, tổ chức, người sử dụng hoặc đơn vị thành viên Thông tin liên quan đến một thực thể không thể phân bố giữa các nút khác nhau mà chỉ thuộc về một nút trong DSA của DIT Đối với tổ chức lớn, thông tin có thể được phân bố trong nhiều DSA Quá trình phân bố thông tin và tạo bản sao giữa các DSA diễn ra một cách trong suốt với người dùng, giúp tránh lỗi tại một điểm đơn lẻ khi không thể truy cập vào một DSA chứa thông tin, đồng thời cải thiện thời gian đáp ứng và chất lượng dịch vụ.
Dịch vụ DUA (Directory User Agent) được sử dụng để truy cập thư mục trong hệ thống X.500, đóng vai trò trung gian giữa người sử dụng và cơ sở dữ liệu thư mục Để lấy thông tin từ thư mục, DUA kết nối với DSA gần nhất để tìm kiếm dữ liệu cần thiết DUA có thể hoạt động qua giao diện người dùng hoặc được tích hợp vào ứng dụng, phục vụ cho việc yêu cầu thông tin lưu trữ trong DIT.
Có thể thực hiện truy vấn ở bất kỳ cấp độ nào trong DIT để tìm kiếm thông tin lưu trữ trong thư mục X.500 bằng cách chỉ định các thuộc tính và giá trị tương ứng.
66 thuộc tính đó DSA kiểm soát các khả năng tìm kiếm bằng cách chỉ ra đối tượng nào có thể được quyền tìm kiếm tới mức nào trong DIT.
Với toàn bộ các đặc tính vừa trình bày ở trên, X.500 đã trở thành dịch vụ thư mục chia sẻ được chấp nhận rộng rãi.
X.509 là một chuẩn PKI để tạo định dạng cho chứng thực điện tử Chuẩn này mô tả mô hình kiến trúc xác thực chéo các chứng thực từ nhiều
Chứng thực X.509 xác thực danh tính cá nhân thông qua cơ chế mật mã, lưu trữ thông tin và quyền hạn của các thực thể dưới dạng thuộc tính Chuẩn X.509 được hỗ trợ bởi nhiều giao thức như PKCS, S-HTTP và SSL Phiên bản đầu tiên của chứng thực X.509 bao gồm các thông tin quan trọng.
• Certificate Version: Phiên bản của chứng thực, giá trị mới nhất là 3.
• Certificate serial number: Đây là giá trị số nguyên duy nhất được CA gán cho mỗi chứng thực.
• Signature Algorithm ID: Đây là số nhận dạng thuật toán được CA sử dụng để ký vào chứng thực.
• Issuer name: Chỉ ra CA đã ký và tạo ra chứng thực
• Validity Period: Chứa 2 mốc thời gian: thời điểm bắt đầu có hiệu lực của chứng thực và thời điểm chứng thực bị hết hạn sử dụng.
Đối tượng sở hữu khóa bí mật là người mà khóa công khai tương ứng được lưu trữ trong trường "subjects public key" trong cặp khóa công khai/bí mật.
• Subject public key information: Chứa khoá công khai cùng với số nhận dạng thuật toán sử dụng khoá công khai này.
• Digital Signature: Chứa chữ ký số của tổ chức phát hành.
Mặc dù chứng thực cung cấp thông tin để định danh thực thể, nhưng không đảm bảo tính duy nhất của tên chủ thể và chứng chỉ CA Có thể xảy ra trường hợp một tên chủ thể duy nhất được gán cho hai thực thể khác nhau Để khắc phục vấn đề này, phiên bản thứ hai của X.509 (X.509 v2) đã được phát triển.
X.509 v2 là phiên bản tiếp theo của chuẩn X.509, trong phiên bản này, ngoài các thông tin nêu ra ở trên còn có thêm 2 trường mới, gồm:
Mã định danh duy nhất của tổ chức phát hành chứng thực là một trường quan trọng, đảm bảo rằng mỗi CA (Certificate Authority) có một số nhận dạng độc nhất, không trùng lặp với bất kỳ CA nào khác, mặc dù trường "tên tổ chức phát hành" đã có sẵn Điều này giúp tăng cường tính minh bạch và bảo mật trong việc xác thực danh tính của các tổ chức phát hành chứng thực.
• Subject unique identifier: Trường này tương tự như “issuer unique identifier”, nó đảm bảo sự duy nhất cho chủ thể của chứng thực.
X.509 v1 và X.509 v2 được dùng chủ yếu cho các quá trình xác thực bên trong một tổ chức Do đó chúng có một số hạn chế liên quan tới kiểu và lượng thông tin được chứa trên chứng thực X.509 phiên bản 3 (X.509 v3) đã được tạo ra nhằm khắc phục các nhược điểm trên X.509 v3 cũng đưa vào những thay đáng kể trong phiên bản 2.
X.509 phiên bản 3: X.509 v3 là phiên bản mới nhất của chuẩn X.509, được giới thiệu vào năm 1996, trong phiên bản này đã đưa vào khái niệm phần mở rộng Phần mở rộng trong phiên bản này chứa các trường lưu thông tin bổ sung cho các trường được định nghĩa trong các phiên bản trước nó Nhờ sử dụng phần mở rộng X.509 v3, một tổ chức có thể định nghĩa nội dung của chứng thực theo các yêu cầu của họ
Để đảm bảo độ tin cậy khi phát hành chứng thư điện tử, CA sử dụng khóa bí mật của mình để tạo chữ ký số cho toàn bộ nội dung chứng thực Chữ ký số này sau đó được đặt vào phần chữ ký số của CA trên chứng thư đó.
Hình 3.4 Tạo chữ ký số cho chứng thực
Chương 4 QUẢN LÝ CH NG THỨ ỰC ĐIỆN T Ử
Quá trình quản lý chứng thực khởi đầu khi người dùng yêu cầu cấp phát chứng thực Chứng thực này sẽ tồn tại trong thời gian hiệu lực được quy định bởi chính sách của CA.
QUẢ N LÝ CH Ứ NG TH Ự C ĐI Ệ N T 69 Ử 4.1 Chính sách và tài liệu cam kết thực hiện chứng thực điện tử
Yêu cầu đăng ký chứng thực điện tử và RA
Quá trình yêu cầu đăng ký chứng thực điện tử bắt đầu khi người sử dụng gửi yêu cầu xin cấp chứng thực đến cơ quan chứng thực (CA) Để hỗ trợ CA trong công việc này, RA có thể được sử dụng nhằm tối ưu hóa quy trình đăng ký.
RA đóng vai trò là cầu nối giữa người dùng và CA, tiếp nhận các yêu cầu cấp phát chứng thực từ người dùng Những yêu cầu này được tạo ra theo định dạng chuẩn mà RA cung cấp Các chức năng chính của RA bao gồm việc xử lý và quản lý các yêu cầu này một cách hiệu quả.
• Kiểm tra tính hợp lệ của người sử dụng trong quá trình nhận yêu cầu xin cấp phát chứng thực.
• Xử lý quá trình yêu cầu cấp phát chứng thực điện tử.
• Chuyển thông tin tới CA để hoàn tất quá trình đăng ký.
Thông thường, RA gồm 3 thành phần: bộ phận giao tiếp người-máy (console), nhân viên nghiệp vụ và người quản lý.
Bộ phận giao tiếp người-máy đóng vai trò là máy chủ tiếp nhận các yêu cầu đăng ký từ người sử dụng Máy chủ này thực hiện việc trao đổi thông tin với các máy chủ của CA, đảm bảo quy trình giao tiếp hiệu quả và an toàn.
Nhân viên nghiệp vụ đóng vai trò quan trọng trong việc xử lý, xác nhận và phê chuẩn các yêu cầu cấp phát chứng thực Khi cơ quan chứng thực (CA) phát hành chứng thực, nhân viên nghiệp vụ sẽ chịu trách nhiệm chuyển giao chứng thực đến tay người sử dụng đã đặt yêu cầu.
4.2.1 Đăng ký chứng thực điện tử
Quá trình đăng ký chứng thực được tiến hành theo các bước được ch ra ỉ trên h 4.1: ình
1) Người sử dụng gửi yêu cầu tới RA xin một bản đăng ký theo mẫu chuẩn mà RA đã tạo sẵn Yêu cầu này có thể được thực hiện trực tuyến phụ thuộc vào chính sách hoạt động của RA.
2) Khi nhận được yêu cầu, RA gửi bản mẫu đăng ký tới người sử dụng.
3) Người sử dụng điền thông tin vào bản đăng ký và gửi tới RA.
4) Dựa vào thông tin trong bản đăng ký, RA xác nhận định danh của người sử dụng và gửi yêu cầu đăng ký tới CA.
5) Sau khi xác nhận yêu cầu, CA gửi thông tin phản hồi tới RA Thông tin phản hồi có thể là một sự từ chối nếu người sử dụng không điền đủ các thông tin quan trọng.
6) Nếu thông tin phản hồi từ CA báo rằng yêu cầu được chấp nhận thì RA sẽ đăng ký người sử dụng và chuyển thông tin đăng ký tới người đó.
Sau khi hoàn tất quá trình đăng ký chứng thực, một cặp khóa được tạo ra, trong đó khóa công khai sẽ được đưa vào chứng thực điện tử Chứng thực này sau đó sẽ được chuyển đến tay người sử dụng.
Hình 4.1 Quá trình đăng ký chứng thực
Cặp khoá có thể được tạo ra bởi người sử dụng hoặc bởi CA Nếu do người sử dụng tạo, khoá công khai sẽ được gửi tới CA kèm theo yêu cầu cấp phát chứng thực Ngược lại, nếu cặp khoá được tạo bởi một bên tin cậy hoặc CA, CA sẽ ký xác nhận và gửi khoá bí mật cho người sử dụng qua một cơ chế bảo mật Ngoài việc cung cấp khoá bí mật, CA cũng phải công bố chứng thực cùng khoá công khai tương ứng trong cơ sở dữ liệu thư mục chung.
Bảo trì khoá và chứng thực điện tử
CA và người sử dụng cần đảm bảo có đủ tài nguyên không chỉ để tạo khóa mà còn để thực hiện sao lưu khóa Sao lưu khóa là một bước quan trọng và cần thiết ngay sau khi khóa được tạo ra.
Một hoạt động quan trọng trong quản lý khóa là thực hiện sao lưu khóa Việc sao lưu này giúp đảm bảo rằng nếu người dùng mất khóa bí mật, dữ liệu đã được mã hóa bằng khóa công khai tương ứng vẫn có thể được giải mã Thông thường, khóa sẽ được sao lưu khi chứng thực điện tử được phát hành.
CA sẽ thực hiện sao lưu khóa Trong trường hợp sử dụng hai cặp khóa, một cặp dùng để ký xác nhận và một cặp dùng để mã hóa, cặp khóa dùng để ký tài liệu không cần thiết phải sao lưu Ngay cả khi khóa ký bị mất, cũng không có dữ liệu mã hóa nào cần giải mã bằng khóa này.
4.3.2 Chứng th c h t hạn và lưu giữự ế ch ng th c ứ ự
Chứng thực liên quan đến khoá công khai của người dùng có thời hạn hiệu lực nhất định và sẽ hết hiệu lực khi quá thời gian này Ngoài ra, chứng thực cũng có thể bị thu hồi trước thời hạn nếu có yêu cầu từ chủ sở hữu Khi đó, CA sẽ cập nhật thông tin về chứng thực đã thu hồi vào danh sách chứng thực bị thu hồi (CRL - Certificate Revocation List).
CA cần đảm bảo khả năng phục hồi hiệu lực cho các chứng thực đã hết hạn, nhằm bảo vệ tính hợp lệ của các giao dịch đã thực hiện trước đó Để làm được điều này, CA phải duy trì thông tin đầy đủ để xác nhận danh tính của đối tượng trong chứng thực, đồng thời đảm bảo rằng chứng thực đã được sử dụng hợp lệ tại thời điểm ký tài liệu trong quá khứ.
4.3.3 Cập nhật chứng thực điện tử
Khi chứng thực hết hạn, một cặp khoá mới được tạo ra và khoá công khai trong cặp khoá này sẽ được gán vào chứng thực Quá trình này gọi là cập nhật khoá, có thể diễn ra tự động khi thời gian sử dụng khoá đạt 70-80% giá trị hiệu lực Khoá mới cần được sử dụng cho các hoạt động mã hoá, dẫn đến giai đoạn chuyển tiếp để các thực thể nhận chứng thực mới.
Trong một khoảng thời gian hợp lý, các thực thể sẽ duy trì quá trình giao dịch mà không bị gián đoạn do các hoạt động chứng thực đã hết hạn.
Khi một chứng thực mới được phát hành, CA cũng sẽ tạo ra các chứng thực chuyển đổi khoá (key rollover certificates) Quá trình thực hiện các chứng thực chuyển đổi khoá này diễn ra đồng thời với việc phát hành chứng thực mới.
Chứng thực thứ nhất bao gồm khoá công khai cũ và được ký bằng khoá bí mật mới, cho phép người dùng chuyển đổi khoá Quá trình chuyển đổi này giúp người sử dụng tạo ra một lộ trình quản lý chứng thực hợp lệ, từ chứng thực hiện tại đến chứng thực được ký bằng khoá bí mật mới.
Chứng thực thứ hai bao gồm khoá công khai mới và được ký bằng khoá bí mật cũ Việc chuyển đổi khoá này cho phép người dùng sử dụng các chứng thực đã được ký bằng khoá bí mật cũ để xây dựng lộ trình chuyển đổi sang chứng thực được ký bằng khoá bí mật mới.
Người dùng có thể xác minh tính hợp lệ giữa các chứng thực của họ bằng cách sử dụng chứng thực được ký bằng khóa bí mật cũ và mới.
4.3.4.Phát hành nhiều chứng thực cho người sử ụ d ng
Khi người dùng ngày càng sử dụng nhiều ứng dụng bảo mật thông tin, số lượng cặp khóa có thể gia tăng Các chứng thực khác nhau được phát hành cho cùng một đối tượng sử dụng thường liên quan đến nhiều ứng dụng khác nhau.
Nếu người dùng sở hữu nhiều cặp khoá, việc có nhiều chứng thực tương ứng là cần thiết, vì định dạng chứng thực điện tử không cho phép sử dụng nhiều hơn một khoá công khai.
Một khoá công khai có thể xuất hiện trong nhiều chứng thực, tạo cơ hội cho hacker thay thế các chứng thực với mục đích xấu Do đó, người dùng có nhiều chứng thực từ CA cần đảm bảo rằng mỗi chứng thực chứa một khoá công khai riêng biệt để phòng ngừa rủi ro bị thay đổi bởi hacker.
Việc sử dụng các khoá bí mật trong giao dịch là một vấn đề quan trọng, thường diễn ra tự động và liên tục Khi một phiên SSL được thiết lập, phần mềm khách có thể tìm kiếm trong các chứng thực của người sử dụng để phát hiện chứng thực có phần mở rộng phù hợp cho SSL và sử dụng khoá bí mật tương ứng để xác thực người dùng Tuy nhiên, việc đưa một khoá công khai vào nhiều chứng thực có thể gây ra rủi ro bảo mật Do đó, cần phân biệt rõ giữa loại khoá và cách thức sử dụng chúng.
Tìm kiếm và xác minh chứng thực điện tử
Sau khi một chứng thực được phát hành, nó có thể trải qua nhiều giai đoạn như hết hiệu lực hoặc bị thu hồi Do đó, việc thiết lập mức độ tin cậy của chứng thực trước khi sử dụng là rất quan trọng để đảm bảo tính đáng tin cậy của chủ sở hữu Xác minh định danh của một người sử dụng bao gồm hai bước: tiếp nhận chứng thực và xác minh tính hợp lệ của chứng thực đó.
4.4.1.Tìm kiếm chứng thực điện tử Để xác minh định danh của một thực thế, cần tìm được chứng thực đã phát hành cho định danh đó và đồng thời cả chứng thực của bản thân CA phát hành chứng thực Việc tìm chứng thực hoàn toàn phụ thuộc vào vị trí lưu giữ của nó Một chứng thực có thể được phân bố bởi phương tiện bảo mật như thư
S-MIME (Secure Multipurpose Internet Mail Extensions) được sử dụng trong 76 điện tử và có thể công khai trong thư mục X.500 Người dùng có thể tìm và tải chứng thực từ thư mục X.500 thông qua giao thức LDAP (Lightweight Directory Access Protocol), cho phép thu thập thông tin như địa chỉ e-mail và khoá công khai CA (Certificate Authority) cung cấp thông tin người dùng mới vào thư mục LDAP và có thể phát hành nhiều chứng thực cho các đối tượng đáp ứng điều kiện cụ thể Thư mục LDAP có thể tích hợp với trình quản lý chứng thực để tự động nhận và cập nhật thông tin chứng thực Việc phát hành chứng thực công khai thường dựa trên thiết lập PKI (Public Key Infrastructure).
4.4.2 Xác minh tính hợp lệ ủa chứng thự c c điện tử
Sau khi tìm thấy chứng thực điện tử, bước tiếp theo là xác minh tính hợp lệ của nó Quá trình xác minh này bao gồm một số bước quan trọng để đảm bảo rằng chứng thực điện tử được công nhận và sử dụng đúng cách.
• Xác minh rằng chữ ký trên chứng thực là hợp lệ.
• Xác minh rằng CA được tin cậy đã phát hành ra chứng thực này
• Đảm bảo rằng chứng thực có thể được dùng cho các mục đích mong muốn.
• Kiểm tra xem chứng thực đã bị huỷ bỏ hay chưa.
Quá trình xác minh đường dẫn chứng thực điện tử liên quan đến việc các bên sử dụng, như Alice và Bob, phải xác minh chứng thực của các Certificate Authority (CA) Để xác minh khoá công khai của Bob, Alice cần lần lượt kiểm tra chứng thực của từng CA cho đến khi xác minh được chứng thực của Bob Quá trình này được gọi là xác minh đường dẫn chứng thực và chiều dài của đường dẫn này có thể ảnh hưởng đến tính hiệu quả của việc xác minh.
Alice cần xác minh 77 chứng thực CA để kiểm tra khóa công khai của Bob Đường dẫn chứng thực bao gồm ba chứng thực: chứng thực CA đầu tiên do CA X cấp cho CA Y, chứng thực CA thứ hai do CA Y cấp cho CA Z, và chứng thực người sử dụng do CA Z cấp cho Bob Khi xác minh, Alice bắt đầu với khóa công khai của CA X để kiểm tra chứng thực đầu tiên, sau đó sử dụng khóa công khai từ chứng thực đầu tiên để xác minh chứng thực thứ hai.
CA Z dùng để xác minh khoá công khai trong chứng thực của Bob.
Các phương pháp thu hồi chứng thực điện tử
Thu hồi chứng thực điện tử là quá trình làm mất hiệu lực của một chứng thực trước khi nó hết hạn Có nhiều lý do dẫn đến việc thu hồi chứng thực điện tử, bao gồm sự thay đổi thông tin, vi phạm điều khoản sử dụng, hoặc khi chứng thực không còn cần thiết.
• Chủ sở hữu của chứng thực điện tử rời khỏi công ty (chuyển công tác).
• Tên hoặc một số thông tin chi tiết của chủ sở hữu thay đổi.
• Tổ chức phát hành chứng thực điện tử không còn tồn tại hoặc mối quan hệ giữa tổ chức phát hành và công ty không còn tồn tại.
• Có sự nghi ngờ về khả năng bị lộ khoá bí mật.
Có thể sử dụng cơ chế công khai định thời hoặc truy vấn trực tuyến Các phương pháp này được mô tả trong phần dưới đây:
Cơ chế công khai định thời sử dụng danh sách CRL, là danh sách các chứng thực đã bị thu hồi trước khi hết hiệu lực CRL được tạo ra, duy trì và cập nhật thường xuyên bởi tổ chức phát hành chứng thực hoặc CA.
Cơ chế truy vấn trực tuyến thường áp dụng OCSP (Online Certificate Status Protocol) để nhận thông tin thu hồi chứng thực một cách nhanh chóng và hiệu quả OCSP cho phép người dùng kiểm tra tình trạng hợp lệ của các chứng chỉ số trực tuyến, đảm bảo an toàn cho các giao dịch và thông tin trực tuyến.
Khi một chứng thực bị thu hồi, thông tin sẽ được công bố trên danh sách thu hồi chứng thực (CRL) Thông thường, tổ chức cấp chứng thực (CA) sẽ định kỳ phát hành CRL cho các chứng thực của mình, và CRL này được ký bởi CA để đảm bảo tính xác thực Quá trình xác minh chứng thực bởi người sử dụng bao gồm bốn bước.
1) Kiểm tra trường chứa thông tin hiệu lực của chứng thực.
2) Nếu chứng thực vẫn chưa hết hạn thì người sử dụng tạo ra một yêu cầu truy vấn CRL gửi tới CA tin cậy của mình.
3) Khi nhận được CRL, người sử dụng xác minh chữ ký số của CA trên CRL.
4) Người sử dụng tìm trong CRL để kiểm tra xem số thứ tự (serial number) của chứng thực có được chỉ ra trên CRL hay không Nếu số thứ tự của chứng thực được chỉ ra trên CRL thì chứng tỏ rằng chứng thực đó đã bị thu hồi.
CRL (Certificate Revocation List) có thể bao gồm thông tin thu hồi chứng thực từ CA, được gọi là ARL (Authority Revocation List) Tuy nhiên, ARL không chứa thông tin thu hồi chứng thực của người sử dụng CRL đã được phát triển cùng với tiêu chuẩn X.509.
CRL phiên bản 1, hay còn gọi là CRL V1, định nghĩa cấu trúc cơ bản của một CRL, bao gồm thông tin cần lưu trữ và chứng thực cần thu hồi Ngoài chữ ký, CRL này còn chứa các thông tin quan trọng khác.
• Serial Number: Chứa số thứ tự của chứng thực được ký bởi CA
• Signature Algorithm Identifier: Chứa thuật toán được sử dụng bởi CA để phát hành chứng thực.
Tên của tổ chức phát hành chứng thực (CA) là một yếu tố quan trọng trong việc xác thực danh tính Đối với các chứng thực CA mức cao, như "root CA", tổ chức này sẽ tự ký vào chứng thực của chính mình, đảm bảo tính hợp lệ và độ tin cậy.
• Validity Period: Chứa mốc thời gian bắt đầu và kết thúc của chứng thực.
• Subject Name: Chứa tên chủ sở hữu của khóa công khai được nhận dạng bởi chứng thực.
Thông tin Khóa Công Khai: Chứa khóa công khai của tổ chức phát hành chứng thực Khóa công khai này, kết hợp với thuật toán được chỉ định trong trường "Identifier Thuật Toán Chữ Ký", sẽ xác định hệ thống mã hóa (crypto-system) sử dụng cho khóa công khai.
CRL V1, lần đầu tiên được phát triển và sử dụng, đã bộc lộ nhiều vấn đề về bảo mật, thiếu cơ chế kiểm soát và không linh hoạt Tuy nhiên, tất cả những hạn chế này đã được khắc phục trong phiên bản 2, CRL V2.
CRL phiên bản 2 đã có những cải tiến đáng kể, bao gồm phần mở rộng nhằm nâng cao tính linh động và sự mềm dẻo so với phiên bản 1 Phần mở rộng này cho phép thêm các thuộc tính bổ sung, mang lại nhiều tiện ích hơn cho người dùng.
81 thuộc tính quản lý cấu trúc chứng thực và phân bố CRL được gán cho người dùng hoặc khóa công khai Các trường trong một CRL được mô tả chi tiết trong hình 4.3.
Các trường trong hình 4.3 thể hiện thông tin sau:
• Version: Chỉ ra phiên bản của CRL Giá trị của trường này nếu được thể hiện luôn là 2 vì trường này được sử dụng đầu tiên trong CRL V2.
• Signature: Chứa định danh (nhận dạng) thuật toán mà CA sử dụng để ký vào CRL
• Issuer: Chứa tên phân biệt duy nhất theo chuẩn X.500 (Distinguished Name) của CA phát hành CRL.
• This update: Chứa mốc thời gian mà CRL đã được tạo ra.
• Next update: Chứa mốc thời gian mà CRL tiếp theo sẽ được phát hành hay đồng nghĩa với CRL hiện tại hết hạn sử dụng
Danh sách các chứng thực bị thu hồi bao gồm các mục tương ứng với từng chứng thực, cung cấp thông tin chi tiết như số thứ tự, ngày thu hồi và phần mở rộng của chứng thực.
CRL Extensions được áp dụng trong CRL V2, cung cấp thông tin bổ sung về CRL và chứng thực điện tử Thông tin này bao gồm lý do thu hồi chứng thực, tên chủ sở hữu chứng thực, ngày hết hiệu lực và mã biểu thị tạm ngừng sử dụng chứng thực.
CRL V2 cũng cho phép người sử dụng định nghĩa phần mở rộng của riêng họ và đưa vào trong chứng thực.
Yếu tố quan trọng trong quản lý CRL là quá trình phân bố chúng Để đơn giản hóa quy trình này và dễ dàng truy cập CRL, một CA có thể định nghĩa nhiều điểm phân bố khác nhau, như điểm cho CRL của người sử dụng và điểm cho CRL của CA Việc này giúp giảm kích thước CRL và nguy cơ tắc nghẽn mạng, đồng thời rút ngắn thời gian xử lý CRL của người sử dụng CA có thể phân bố CRL dựa trên yêu cầu của doanh nghiệp, chia CRL theo các bộ phận và phát hành cho người sử dụng trong bộ phận đó Ví dụ, James từ bộ phận nghiên cứu có thể xác nhận chứng thực của Charlie từ bộ phận kinh doanh mà không cần truy vấn toàn bộ CRL của tổ chức Tuy nhiên, quá trình phân định CRL có giới hạn, vì điểm phân bố sẽ được xác định khi chứng thực được phát hành và không thể thay đổi sau đó Do đó, sự phân chia CRL không hoàn toàn linh động, đặc biệt khi kích thước CRL tăng Giải pháp CRL chuyển tiếp (redirect CRL) được đưa ra nhằm cải thiện tính linh động trong việc quyết định các điểm phân bố.
4.5.1.2.CRL chuyển tiếp (Redirect CRL)
THIẾ T K H TH NG CH NG TH Ế Ệ Ố Ứ Ự C ĐI Ệ N T Ử Ứ NG D Ụ NG
Quy trình nghiệp vụ hệ thống thông quan điện tử hải quan
Qui trình thủ tục hải quan điện tử được tiến hành theo các bước sau:
Doanh nghiệp tiến hành kê khai hải quan điện tử và gửi dữ liệu đến Chi cục Hải quan điện tử Hệ thống tiếp nhận tờ khai điện tử, kiểm tra điều kiện tham gia của doanh nghiệp và tính logic của các tiêu chí khai báo Sau khi hoàn tất kiểm tra, hệ thống sẽ phản hồi cho doanh nghiệp về tình trạng hồ sơ (hợp lệ hoặc không hợp lệ) Nếu hồ sơ hợp lệ, tờ khai điện tử sẽ được cấp số chính thức và chuyển sang giai đoạn phân luồng.
Bước 2 trong quy trình là khâu phân luồng, do cán bộ tiếp nhận thực hiện, nhằm đề xuất phương án phân loại hàng hóa Hàng hóa và vật phẩm xuất khẩu, nhập khẩu sẽ được chia thành ba luồng hàng khác nhau.
• Hàng luồng xanh: Gồm tài liệu, chứng từ thương mại, hàng không có thuế, hàng có thuế nhưng được miễn thuế theo quy định của pháp luật.
• Hàng luồng vàng: Hàng phải nộp thuế
• Hàng luồng đỏ: Hàng thuộc diện quản lý chuyên ngành, hàng phải kiểm tra nhà nước về chất lượng, hàng nhập khẩu có điều kiện, hàng trọng điểm.
Lãnh đạo chi cục hải quan điện tử sẽ duyệt phân luồng dựa trên đề xuất đã nhận Sau đó, cán bộ tiếp nhận sẽ gửi thông báo hướng dẫn thủ tục hải quan điện tử cho doanh nghiệp, bao gồm các thông tin quan trọng như phân luồng, số tờ khai và thông báo thuế.
• Đối với hàng hóa thuộc luồng xanh: Miễn kiểm tra; chấp nhận thông quan hàng hóa Chuyển sang bước 5.
• Đối với hàng hóa thuộc luồng vàng: Kiểm tra hồ sơ trước khi thông quan Chuyển sang bước 4.
• Đối với hàng hóa thuộc luồng đỏ: Kiểm tra hồ sơ và thực tế hàng hóa trước khi thông quan Chuyển sang bước 4.
Bước 4 trong quy trình thông quan là chấp nhận thông quan, trong đó cán bộ kiểm tra hồ sơ sẽ dựa vào kết quả kiểm tra hồ sơ và/hoặc kiểm tra thực tế hàng hóa để quyết định việc chấp nhận thông quan.
Bước 5 trong quy trình xác nhận thực xuất và thực nhập là cán bộ giám sát sẽ dựa vào kết quả chấp nhận thông quan Họ sẽ in lệnh thông quan từ hệ thống, sau đó ký và đóng dấu xác nhận lên lệnh này.
Mô hình truyền thông
Hệ thống mạng WAN toàn ngành hải quan đã được triển khai, tuy nhiên, chủ yếu vẫn sử dụng các kết nối quay số qua MODEM Async với tốc độ 56Kbps.
Here is a rewritten paragraph that complies with SEO rules:"Hiện nay, chỉ có 3 cục hải quan đã được kết nối trực tuyến sử dụng leased line với tốc độ 64/128Kbps, giúp kết nối về Tổng cục hải quan một cách ổn định Đặc biệt, tại 3 cục hải quan này còn có một số đường kết nối khác, góp phần tăng cường hiệu quả trong quá trình trao đổi dữ liệu."
Hiện tại, 89 chi cục Hải quan đang sử dụng mạng kết nối tương đối chậm với phương thức truyền dữ liệu đơn giản và không bảo mật Tuy nhiên, trong thời gian tới, mạng WAN của Hải quan sẽ được nâng cấp, với kế hoạch kết nối tất cả các Cục về Tổng cục bằng đường truyền 2Mbps (dự phòng 512Kbps) Kết nối giữa các Chi cục với Cục sẽ đạt 256K (dự phòng 64Kbps), trong khi kết nối backbone trục Bắc Nam sẽ là 2 x 2Mbps.
Le as ed li ne
Cục Hải quan Hải Phòng -
Cục Hải quan Đồng Nai - PSTN
Chi Cục Hải quan Hải Phòng -
Cục Chi cục Hải quan các Tỉnh /
Chi Cục Hải quan Đồng Nai -
Le as ed li ne
Le as ed li ne
Hình 5.1 Mạng WAN của Hải quan
Phương thức truyền nhận dữ liệu giữa Chi cục và Cục được thực hiện thông qua giao dịch hàng ngày với các doanh nghiệp, chủ yếu tại các chi cục Hải quan cửa khẩu Cán bộ hải quan tiếp nhận tờ khai hải quan và cập nhật trực tiếp vào CSDL trên máy chủ Chi cục qua các cửa sổ ứng dụng Hàng ngày, cán bộ phụ trách thực hiện việc kết xuất và truyền dữ liệu theo quy định về thời gian.
90 việc truyền nhận sẽ chạy một chương trình chuyên dụng để truyền dữ liệu Nguyên tắc hoạt động như sau:
Trên máy chủ local tại chi cục, mỗi ứng dụng cần truyền dữ liệu sẽ có một thư mục riêng để gửi và nhận thông tin Thư mục này được xác định và khai báo trong chương trình truyền nhận dữ liệu.
• Trên máy truyền tin tại cục cũng có các thư mục gửi, nhận tương ứng với mỗi ứng dụng và chi cục.
• Mỗi chi cục được cấp một username và password để truy cập tới thư mục chia sẻ trên máy chủ truyền tin cục.
Khi cán bộ chi cục chạy chương trình truyền nhận, dữ liệu từ CSDL chi cục sẽ tự động được xuất thành file và lưu vào thư mục gửi trên máy local Sau đó, chương trình sẽ kết nối với máy chủ truyền tin trên cục bằng các thông số username/password và tên thư mục chia sẻ, mà thư mục này sẽ được ánh xạ như một ổ đĩa mạng trên máy local.
• Việc truyền nhận dữ liệu giữa máy chủ chi cục và cục thông qua việc copy các file tại các thư mục định sẵn.
Khi thực hiện kết xuất dữ liệu trên máy chủ cục, chương trình truyền nhận sẽ truy cập vào cơ sở dữ liệu tại cục để xuất dữ liệu và lưu trữ thành file trong các thư mục chia sẻ Đặc biệt, dữ liệu cần được lưu ở hai vị trí: một là thư mục gửi cho chi cục và hai là gửi lên Tổng cục.
Phương thức truyền nhận dữ liệu giữa Cục và Tổng cục tương tự như giữa Chi cục và Cục, sử dụng ánh xạ thư mục gửi và nhận trên máy chủ từ xa Quá trình này bao gồm việc sao chép các file dữ liệu trong các thư mục đó.
Qua khảo sát quy trình nghiệp vụ và phương thức truyền nhận dữ liệu, nhận thấy việc truyền dữ liệu hiện tại còn đơn giản, thủ công và thiếu bảo mật Không có phương thức xác định hay xác thực nội dung dữ liệu, người truyền nhận, dẫn đến rủi ro trong các giao dịch điện tử Chứng cứ trong giao dịch điện tử đóng vai trò quan trọng, đặc biệt khi xảy ra tranh chấp Để mở rộng hoạt động nghiệp vụ qua môi trường mạng và tận dụng sức mạnh của Internet, cần thiết phải thiết kế một mô hình an toàn bảo mật tổng thể và triển khai hệ thống chứng thực điện tử cho ngành Hải quan.
Thiết kế hệ thống chứng thực điện tử cho ngành Hải quan
Với sự phát triển của các hoạt động nghiệp vụ trên Internet, việc áp dụng công nghệ chứng thực điện tử trong toàn ngành Hải Quan trở nên thiết yếu Công nghệ này sẽ giúp tăng cường tính bảo mật, nâng cao hiệu quả quản lý và tiết kiệm thời gian trong các thủ tục hải quan.
• Bảo đảm tính toàn vẹn của dữ liệu trao đổi trên đường truyền
• Bảo đảm tính đúng đắn, không thể từ chối được thông tin đã gửi đi
• Bảo đảm chính xác những ai có thẩm quyền, mới được phép làm việc
5.3.1 Mô hình tổ chức của ngành Hải quan
Theo cấu trúc tổ chức trong toàn ngành Hải Quan, đứng đầu là Tổng cục Hải Quan, tiếp đến là các Cục, dưới Cục là các Chi cục (hình 5.2)
Hình 5.2 Cấu trúc toàn ngành Hải Quan
Tổng cục Hải quan, thuộc Bộ Tài chính, là cơ quan chịu trách nhiệm quản lý nhà nước về hải quan và thực thi pháp luật hải quan trên toàn quốc.
• 15T Các Cục Hải quan tỉnh, liên tỉnh, thành phố trực thuộc Trung ương, trực thuộc Tổng cục Hải quan
• 15T Các Chi cục Hải quan cửa khẩu, Đội kiểm soát Hải quan và đơn vị tương đương trực thuộc hải quan địa phương.
Cục Hải quan tỉnh, thành phố phân công nhiệm vụ cho Chi cục Hải quan gần Cảng thực hiện thủ tục hải quan cho hàng hóa xuất nhập khẩu và phương tiện vận tải xuất nhập cảnh qua Cảng, đồng thời đảm bảo kiểm soát và giám sát khu vực.
Mô hình tổ chức trong ngành Hải quan được cấu trúc theo dạng cây, với các đơn vị như Cục và Chi cục có chức năng ngang nhau và hoạt động nghiệp vụ đồng nhất nhưng độc lập Tương tác giữa doanh nghiệp và Chi cục Hải quan diễn ra trực tiếp, cho phép doanh nghiệp sử dụng máy tính kết nối mạng để khai báo và truyền thông tin về hàng hóa xuất nhập khẩu Điều này đóng vai trò quan trọng trong việc lựa chọn kiến trúc cho hệ thống chứng thực CA.
5.3.2 Lựa chọn mô hình thiết kế CA
Mô hình kiến trúc PKI phân cấp là sự lựa chọn hợp lý cho ngành Hải quan, phản ánh cấu trúc tổ chức của ngành này Trong quá trình giao dịch, các doanh nghiệp và Chi cục Hải quan tương tác trực tiếp, với vai trò là những thực thể đầu cuối Tổng cục Hải quan có quyền cấp phát Chứng thực viên (CA) cho các Cục Hải quan, giúp họ chủ động cấp phát chứng thực số cho các Chi cục và doanh nghiệp thuộc quyền quản lý Như vậy, hệ thống CA của ngành Hải quan sẽ được thiết kế theo mô hình phân cấp.
• Mô hình hình cây phân cấp cho toàn ngành Hải quan.
• Có một CA gốc (Root CA) tạo một điểmtin cậy duy nhất cho toàn ngành.
Tại mỗi cục Hải quan, sẽ có CA cấp thấp (Sub CA) đảm nhiệm việc cấp và quản lý chứng thực cho các thành phần thuộc quyền quản lý nội bộ của cục, bao gồm cả chi cục và doanh nghiệp.
CA của Tổng cục Hải quan là cấp cao nhất trong hệ thống CA của ngành Hải quan, có nhiệm vụ quản lý và chứng thực Dưới Tổng cục, các CA cấp thấp thuộc các Cục sẽ cấp chứng thực cho các Chi cục và doanh nghiệp Các Chi cục và doanh nghiệp đóng vai trò là người dùng cuối trong hệ thống này.
Hình 5.3 Mô hình logic hệ thống CA của TCHQ
Mô hình CA đơn nhất cho ngành Hải quan có ưu điểm quản lý đơn giản và chi phí thấp, nhưng chỉ phù hợp với các tổ chức nhỏ do tính khả mở và yêu cầu an toàn không cao Việc chỉ có một CA duy nhất trong hệ thống làm tăng nguy cơ bị tấn công từ tin tặc, và nếu CA gặp sự cố, tất cả dịch vụ như phát hành chứng thực và thông báo danh sách chứng thực bị huỷ bỏ sẽ bị đình trệ Hơn nữa, nếu khoá bí mật của CA bị lộ, tất cả chứng thực phát hành sẽ bị vô hiệu hoá.
Trong mô hình phân cấp CA 2 lớp, chúng ta sử dụng một CA gốc (root CA) và nhiều CA cấp thấp ở mức thứ 2 để phát hành chứng thực cho các thực thể đầu cuối Để tăng cường an toàn bảo mật, CA gốc có thể hoạt động ở trạng thái ngoại tuyến, tách biệt khỏi mạng và được bảo vệ vật lý trong một phòng máy chủ an toàn Tất cả chứng thực cho các đối tượng đầu cuối sẽ được phát hành bởi các CA cấp 2, tạo ra đường dẫn chứng thực tới CA gốc Việc phát hành CRL sẽ được thực hiện định kỳ theo chế độ nhân công.
Trong mô hình PKI phân cấp, các CA cấp 2 có thể được tổ chức theo ứng dụng như Secure Email, VPN, EFS, theo vùng miền địa lý hoặc theo cấu trúc tổ chức của ngành Mỗi đơn vị trong cùng một cấp (Cục hoặc Chi cục) có chức năng tương đương và thực hiện các hoạt động nghiệp vụ đồng nhất, đồng thời độc lập với nhau Tương tác giữa các doanh nghiệp và Chi cục Hải Quan diễn ra trực tiếp, do đó, việc lựa chọn kiến trúc PKI phân cấp theo cấu trúc ngành Hải quan là hợp lý nhất.
• Hệ thống máy chủ chứng thực số cần được đặt trong khu vực đảm bảo an toàn và bảo mật.
• Sử dụng 2 cặp khóa: 1 cặp chuyên dùng để ký và 1 cặp chuyên dùng để mã hóa dữ liệu.
CA không nên cấp phát chứng thực cho thực thể đầu cuối có thời gian hiệu lực vượt quá thời gian hiệu lực của chứng thực CA Đồng thời, cần đảm bảo thời gian hiệu lực của chứng thực root CA phải tối thiểu gấp đôi thời gian hiệu lực lớn nhất của chứng thực Sub-CA tại các cơ quan quản lý.
• Chức năng chứng thực điện tử (mã hoá, ký điện tử) chỉ áp dụng cho các thông điệp trao đổi giữa Hải Quan và oanh nghiệp.d
Thiết kế chi tiết các chính sách quản trị và phân quyền hợp lý là yếu tố quan trọng nhằm tăng cường an ninh cho hệ thống và nâng cao hiệu quả trong vận hành quản trị.
• Thiết kế chi tiết chính sách giám sát hệ thống nhằm trợ giúp người quản trị trong việc đặt nhật ký và theo dõi vận hành của hệ thống.
Thiết kế một chính sách sao lưu và phục hồi dữ liệu chi tiết cho hệ thống là rất quan trọng, nhằm đảm bảo khả năng khôi phục nhanh chóng khi xảy ra rủi ro hoặc thảm họa.
• Đưa ra các chuẩn cho phép hệ thống thực hiện chứng thực chéo với những hệ thống chứng thực điện tử khác.
• Phân cấp quản trị các máy chủ CA và RA.
• Thiết lập thêm 1 máy chủ dự phòng cho máy chủ CA và cài đặt ở chế độ đồng bộ dữ liệu theo thời gian thực (Cơ chế Cluster).
Để đảm bảo an toàn trong quá trình khôi phục hệ thống sau sự cố, cần thiết lập cấu hình yêu cầu sự đồng ý từ hai khóa của hai người: một là quản trị hệ thống và một là lãnh đạo.
• Trong trường h ợpkhông thực ện hi c ơ chế hoạt động ngoại tuyếncho R t oo
CA nên sử dụng thiết bị bảo mật HSM (Hardware Security Modules) để bảo vệ khoá bí mật của mình Việc sử dụng HSM giúp đảm bảo rằng khoá bí mật không được lưu trữ trên máy chủ CA mà được bảo mật an toàn trong thiết bị HSM.