Một chữ ký số được đính kèm với thông báo để xác định danh tính người gửi thông báo đó. Để tạo ra một chữ ký số và đính kèm nó đến thông báo cần thực hiện như sau:
1. Biến đổi thông báo ban đầu thành một chuỗi có độ dài cố định bằng cách áp dụng hàm băm trên thông báo. Quá trình này có thể gọi là băm thông báo, chuỗi có độ dài cố định được xem gọi là bản tóm lược thông báo
2. Mã hóa bản tóm lược thông báo bằng khóa riêng của người gửi. Kết quả của tóm lược thông báo đã mã hóa là chữ ký số.
3. Đính kèm chữ ký số với thông báo ban đầu 3.2.4. Mã hóa thông báo
Sau khi áp dụng chữ ký số lên thông báo ban đầu, để bảo vệ nó ta sẽ
mã hóa. Để mã hóa thông báo và chữ ký số, sử dụng mật mã khóa đối xứng. Khóa đối xứng này được thỏa thuận trước giữa người gửi và người nhận thông báo và chỉ được sử dụng một lần cho việc mã hóa và giải mã.
3.2.5. Truyền khóa đối xứng.
Sau khi mã hóa thông báo và chữ ký số, khóa đối xứng mà được sử dụng để mã hóa cần truyền đến người nhận. Bản thân khóa đối xứng cũng được mã hóa vì lý do an toàn, nếu bị lộ thì bất kỳ người nào cũng có thể giải mã thông báo. Do đó, khoá đối xứng sẽ được mã hoá bằng khoá công khai của người nhận. Chỉ có người nhận mới có thể giải mã được khóa đối xứng bằng việc sử dụng khóa riêng tương ứng. Sau khi đã được mã hóa, khóa phiên và thông báo sẽ được chuyển đến người nhận thông báo.
3.2.6. Kiểm tra danh tính người gửi thông qua một CA
CA đóng vai trò là một bên thứ 3 tin cậy để xác minh danh tính của các thực thể đang tham gia trong quá trình giao dịch. Khi người nhận nhận một bản mã, người nhận có thể yêu cầu CA kiểm tra chữ ký số đính kèm theo thông báo đó. Dựa trên yêu cầu đó, CA kiểm tra chữ ký số của người gửi thông báo.
3.2.7. Giải mã thông báo và kiểm tra nội dung thông báo.
Sau khi nhận thông báo đã được mã hoá, người nhận cần giải mã. Bản mã chỉ có thể được giải mã bằng khóa đối xứng đã được mã hoá. Vì vậy, trước khi giải mã thông báo, khóa đối xứng phải được giải mã bằng khóa riêng của người nhận. Sau khi đã giải mã khoá đối xứng, khoá đối xứng sẽ được dùng để giải mã thông báo.Chữ ký số đính kèm với thông báo được giải mã bằng khóa công khai của người gửi và bản tóm lược thông báo được bóc tách ra từ nó. Người nhận sau đó sẽ tạo ra một bản tóm lược thông báo thứ hai. Cả hai thông báo băm sau đó được so sánh để kiểm tra xem có bất kỳ sự giả mạo của thông báo xảy ra trong quá trình truyền tin không. Nếu hai thông báo băm trùng khít nhau chứng tỏ thông báo không bị giả mạo trong khi truyền.
Các tiêu chí cơ bản của một giao dịch điện tử:
Chống chối bỏ: Tất cả các thực thể liên quan trong giao dịch không thể từ chối mình là một phần của giao dịch đó.
Truyền tin an toàn: Đây là một cơ chế đúng đắn để đảm bảo an toàn thông báo trong truyền tin. Bất kỳ sự giả mạo hoặc thay đổi được làm trên thông báo phải được phát hiện dễ dàng.
Tính riêng tư: Bất kỳ sự truy nhập bất hợp pháp đến thông báo đều bị từ chối.
Sự xác thực: Để định danh các thực thể đang là một phần liên lạc trong quá trình giao dịch thì cân phải biết đến cả hai thực thể.
Tính ràng buộc: Giao dịch nên được kiểm tra và được ký bởi các bên liên quan.
PKI đảm bảo rằng tất cả các giao dịch có thể đáp ứng các yêu cầu hợp pháp bằng cách cung cấp cơ sở hạ tầng và môi trường cần thiết .
3.3. Các tiến trình trong PKI
Các ứng dụng có thể đạt được các chức năng an toàn khi sử dụng PKI. Các chức năng an toàn đó là tính bí mật, tính toàn vẹn, tính xác thực và tính chống chối bỏ
Mỗi một tiến trình trong PKI sẽ thực hiện các yêu cầu an toàn đã được đề cập ở trên.
3.3.1. Yêu cầu chứng chỉ
Để có được chứng chỉ số từ CA, người dùng cần gửi yêu cầu chứng chỉ. Có rất nhiều chuẩn để gửi yêu cầu chứng chỉ và chuẩn phổ biến nhất đó là PKCS#10. Yêu cầu chứng chỉ chứa các trường sau
Tên phân biệt của CA
Khoá công khai của người dùng Tên thuật toán
Chữ ký số của người dùng
Người dùng gửi yêu cầu chứng chỉ PKCS tới cho CA thông qua một kênh an toàn. Nếu kênh này không được đảm bảo an toàn, thì người dùng tải khoá công khai của CA và mã hoá yêu cầu này bằng khoá công khai của CA
3.3.1.1. Gửi yêu cầu
Yêu cầu chứng chỉ được gửi cho tới CA bằng một thư điện tử, sử dụng PEM (Privacy). Yêu cầu chứng chỉ phải được gửi trong định dạng PEM bởi vì yêu cầu ban đầu được tạo ra bằng mã nhị phân. Mã nhị phân này không thể được truyền bằng email.
Với chữ ký số trong yêu cầu chứng chỉ, CA có thể chắc chắn rằng người gửi có một khoá riêng tương ứng với khoá công khai. Do đó, người gửi được chứng minh sở hữu (adsbygoogle = window.adsbygoogle || []).push({});
Client cũng có thể đưa ra yêu cầu khoá thông qua trình duyệt Web. Trong trường hợp này, PKCS#10 được sử dụng cùng với SSL. Client thực hiện một
kết nối SSL với máy chủ chứng chỉ và sau đó truyền yêu cầu chứng chỉ thông qua một kênh an toàn
3.3.1.2. Các chính sách
Chính sách an toàn định nghĩa một hướng dẫn cho tổ chức để đảm bảo an toàn thông tin, các tiến trình và các nguyên tắc sử dụng mật mã. Chính sách định nghĩa tổ chức đó quản lý khoá công khai, khoá riêng và các thông tin khác như mức kiểm soát được yêu cầu để quản lý các nhân tố gây mất an toàn như thế nào
Một vài hệ thống PKI được vận hành bởi bên thứ ba tin cậy được gọi là thẩm quyền chứng thực thương mại (Commercial Certificate Authorites) và do đó sẽ yêu cầu một CPS (Certification Pratice Statement). CPS định nghĩa các chính sách sẽ được triển khai và hỗ trợ như thễ nào, chứng chỉ sẽ được cấp phát, được chấp nhận và bị thu hồi như thế nào và khoá công khai sẽ được tạo, được đăng ký và được chứng thực như thế nào. CPS cũng định nghĩa vị trí của những khoá này
3.3.2. Huỷ bỏ chứng chỉ
Mỗi chứng chỉ đều có một giai đoạn hợp lệ. Giai đoạn hợp lệ của chứng chỉ được tính từ thời gian chứng chỉ được cấp phát tới khi chứng chỉ hết hạn. Tuy nhiên, có những trường hợp, chứng chỉ bị mất tính hợp lệ trước khoảng thời gian hết hạn. Trong trường hợp này, chứng chỉ cũng được phép tiếp tục sử dụng. Tình huống này nảy sinh khi độ an toàn của chứng chỉ không còn (ví dụ như lộ khoá). Khi chứng chỉ bị mất tính hợp lệ của nó trước thời hạn, thì được gọi là huỷ bỏ chứng chỉ.
Chứng chỉ bị huỷ bỏ sẽ phải được công khai . Thông tin về chứng chỉ bị huỷ bỏ sẽ được công bố trên máy chủ chứng chỉ sao cho người dùng có thể được cảnh báo những chứng chỉ đó.
Một cách thông thường khác cũng hay được sử dụng đó là sử dụng danh sách hủy bỏ chứng chỉ.
3.4. Các mô hình PKI
3.4.1. Mô hình phân cấp CA chặt chẽ (strict hierarchy of CAs)
Trong mô hình này, có 1 CA đóng vai trò là CA gốc ở trên cùng, phía dưới là các nhánh mở rộng và các lá ở cuối cùng
RootCA đóng vai trò như là gốc tin cậy (hay còn gọi là “nguồn tin cậy”) cho toàn bộ miền của các thực thể PKI dưới nó. Ở dưới root CA có thể không có hoặc có một vài lớp intermediate CA (hay còn gọi là subCA)
Hình 11: Mô hình phân cấp CA chặt chẽ
RootCA không đơn giản là điểm khởi đầu của một mạng, hay các kết nối, nó còn là điểm khởi đầu của sự tin cậy. Tất cả các thực thể trong miền đều nắm giữ khoá công khai của CA
Trong mô hình này, tất cả các thực thể trong kiến trúc tin cậy rootCA. Sự phân cấp được thiết lập như sau
RootCA được xây dựng, và tự cấp chứng chỉ cho mình (hay tự ký cho mình)
Mỗi một CA như trên lại chứng thực cho CA trực tiếp dưới nó Tại mức gần cuối cùng, CA sẽ chứng thực thực thể cuối
Mỗi thực thể trong phân cấp phải được cung cấp bản sao khoá công khai của root CA. Quá trình tạo khoá công khai này là cơ sở cho quá trình chứng thực tất cả các kết nối sau đó, do đó, quá trình này phải được thực hiện trên một cách an toàn
Chú ý rằng trong mô hình phân cấp chặt chẽ đa mức (multilevel strict hierarchy), các thực thể cuối được chứng thực (nghĩa là được cấp chứng chỉ) bởi CA trực tiếp ngay trên nó, nhưng gốc tin cậy thì lại là rootCA.
3.4.2.Mô hình phân cấp CA không chặt chẽ (loose hierarchy of CAs)
Trong mô hình phân cấp CA không chặt chẽ các bên được chứng thực bởi cùng một CA để giải quyết vấn đề đường dẫn tin cậy mà không liên quan tới bất kỳ CA mức cao hơn, bao gồm cả root CA. Nghĩa là nếu hai thực thể (ví dụ thực thể A và thực thể B) được chứng thực bởi cùng một CA, thì thực thể A và thực thể B có thể kiếm tra tính hợp lệ của nhau mà không cần phải tạo một đường dẫn chứng thực tới root CA. Về cơ bản, thực thể A và thực thể B cùng thuộc về phân cấp chủ thể tin cậy của cả hai. Tuy nhiên, giả sử rằng có một thực thể C nào đó được chứng thực bởi một CA khác (không phải CA chứng thực cho A và B) thì thực thể A và B phải thực hiện một đường dẫn chứng thực hoàn toàn thông qua rootCA trước khi tin cậy chứng chỉ của C
3.4.3.Mô hình kiến trúc tin cậy phân tán (distributed trust architecture)
Kiến trúc tin cậy phân tán sẽ phân phối sự tin cậy giữa hai hay nhiều CA.
Nghĩa là thực thể 1 có thể giữ bản sao khoá công khai của CA1 như nguồn tin
cậy của mình, thực thể 2 có thể giữ bản sao khoá công khai của CA2 như
nguồn tin cậy của mình. Bởi vì những khoá công khai của những CA này đóng vai trò như nguồn tin cậy (CA1 là gốc(root) của hệ thống phân cấp chứa thực thể 1, CA2 là gốc của hệ thống phân cấp có chứa thực thể 2)
Nếu mỗi kiến trúc phân cấp này là kiến trúc phân cấp không chặt chẽ, thì cấu hình của kiến trúc đó được gọi là kiến trúc được chia điểm (peered
architeture) bởi vì tất cả các CA đều là những điểm hoàn toàn độc lập (Không có SubCA trong kiến trúc). Trái lại, nếu kiến trúc đó là phân cấp đa mức, thì kiến trúc đó được gọi là kiến trúc hình cây (treed architeture) (chú ý rằng các root CA là các điểm so với các CA khác nhưng mỗi root lại đóng vai trò như CA cấp cao đối với một hoặc nhiều SubCA)
Hình 12: Mô hình kiến trúc tin cậy phân tán (adsbygoogle = window.adsbygoogle || []).push({});
Thông thường thì kiến trúc được chia điểm thường được xây dựng trong một miền của một tổ chức (ví dụ trong một công ty), trái lại, kiến trúc hình cây và kiến trúc lai (hybrid architeture) được hình thành từ các miền của các tổ chức khác nhau
Quá trình của việc tạo kết nối mỗi root CA thông thường được gọi là chứng thực chéo (cross-certification)
Hình 13: Mô hình bốn bên
Trong mô hình này minh họa bốn góc của mô hình tin cậy là người thuê bao (subscriber), bên tin cậy (relying party), thuê bao của CA (subscriber’s CA) và bên tin cậy của CA (relying party’s CA)
Mô hình tin cậy 4 bên này thường được triển khai trong các giao dịch thanh toán điện tử
Trong mô hình này , thuê bao sử dụng chứng chỉ được cấp bởi CA của nó Thuê bao và bên tin cậy tương tác và ràng buộc nhau trong các giao dịch điện tử
Bên tin cậy tương tác với miền CA (CA domain) của nó để xác thực cho mỗi phiên giao dịch
Miền CA tương tác khi có yêu cầu xác minh tính hợp lệ/cấp quyền phiên giao dịch
3.4.5. Mô hình Web (web model)
Mô hình Web – đúng như tên gọi của nó, phụ thuộc vào các trình duyệt Web phổ biến như Netscape Navigator và Microsoft Internet Explorer. Trong
mô hình này, số lượng khoá công khai của CA sẽ được cài đặt sẵn vào một số các trình duyệt. Các khoá này sẽ định nghĩa tập hợp các CA mà trình người dùng trình duyệt ban đầu sẽ tin tưởng và xem như các root cho việc xác minh chứng chỉ
Hình 14: Mô hình Web
Mỗi nhà cung cấp trình duyệt đều có root của riêng mình, và nó sẽ chứng thực root CA mà được nhúng trong trình duyệt.
Mô hình Web có những ưu điểm rõ rệt để thuận tiện và đơn giản khả năng liên kết. Tuy nhiên, có một vài sự vấn đề an toàn cần được quan tâm trong mô hình này khi quyết định triển khai. Ví dụ, bởi vì người dùng trình duyệt tự động tin tưởng vào tập hợp các khoá đã được cài sẵn trong trình duyệt, nên an toàn sẽ có thể bị mất nếu một trong số các rootCA đó “rơi vào tình trạng nguy hiểm”
Một vấn đề an toàn nữa cũng cần phải được quan tâm đó là trong mô hình Web, không có cơ chế thực thế nào có thể thu hồi bấy kỳ khoá của root đã được nhúng trong trình duyệt. Nếu chúng ta phát hiện ra một trong những CA “đang trong tình trạng nguy hiểm” hoặc khoá riêng tương ứng với bất kỳ khoá công khai của root bị lộ, thì hiển nhiên là không thể tiếp tục sử dụng khoá đó trong hàng triệu các trình duyệt web trên thế giới
3.4.6.Mô hình tin cậy lấy người dùng làm trung tâm (user-centric trust)
Trong mô hình tin cậy lấy người dùng làm trung tâm, mỗi người dùng sẽ phải chịu trách nhiệm trực tiếp và toàn bộ để quyết định xem sẽ sử dụng chứng chỉ nào và từ chối chứng chỉ nào. Mỗi người dùng sẽ giữ một vòng khoá và vòng khoá này đóng vai trò như CA của họ. Vòng khoá này chứa các khoá công khai được tin cậy của những người sử dụng khác trong cộng đồng. Mô hình này được Zimmerman phát triển để sử dụng trong chương trình phát triển phần mềm bảo mật PGP
Quyết định này có thể chịu ảnh hưởng của một số các nhân tố, mặc dù ban đầu tập hợp các khoá được tin cậy thông thường bao gồm các nhân tố là bạn bè, gia đình, đồng nghiệp …
Hình 15: Mô hình tin cậy lấy người dùng làm trung tâm
Mô hình này được sử dụng rộng rãi trong phần mềm an ninh nổi tiếng là Pretty Good Privacy (PGP) [Zimm95, Garf95]. Trong PGP, người dùng xây dựng mạng lưới tín nhiệm (web of trust) đóng vai trò là CA (ký lên khoá công khai cho các thực thể khác)
Do sự tín nhiệm của người dùng trong các họat động và các quyết định, nên mô hình tin cậy lấy người dùng làm trung tâm có thể họat động được trong cộng đồng đòi hỏi kỹ thuật và sự quan tâm cao độ, nhưng nó không thực tế đối với cộng đồng chung (cộng đồng mà trong đó nhiều người dùng chỉ có một chút hoặc không có sự hiểu biết về các khái niệm PKI hay khái niệm an toàn). Hơn nữa, một mô hình như vậy thông thường không phù hợp với các môi trường của công ty, tổ chức tài chính hoặc chính phủ
3.5.Các kiểu kiến trúc PKI
Có một vài kiểu kiến trúc mà PKI có thể triển khai để cung cấp “chuỗi tin cậy” từ một khoá công khai đã biết nhằm xác thực thông qua khoá công khai cụ thể của người dùng. Ví dụ khi người dùng xác thực họ với các ứng dụng của với e-Government, thì phần mềm ứng dụng mật mã sẽ xác minh chữ ký trong chứng chỉ của người dùng bằng cách sử dụng khoá công khai của CA mà tạo ra chứng chỉ đó. Nếu khoá của CA không phải là khoá của root, thì chứng chỉ chứa nó cũng sẽ phải được xác minh tính hợp lệ bằng khoá công khai mà ký chứng chỉ đó. Và tiếp tục đến khi nào chứng chỉ trong “chuỗi tin