Các mô hình hạ tầng khóa công khai – PKI (2)


Xem thêm:
Tổng quan về hạ tầng khóa công khai (PKI) – Phần 1
Tổng quan về hạ tầng khóa công khai (PKI) – Phần 2
Tổng quan về hạ tầng khóa công khai (PKI) – Phần 3
Tổng quan về hạ tầng khóa công khai (PKI) – Phần 4
Tổng quan về hạ tầng khóa công khai (PKI) – Phần 5

————-

Tùy vào các yêu cầu, quy mô và khả năng của từng tổ chức mà có thể chọn triển khai một trong 3 mô hình PKI phổ biến sau:

  • Hierarchical PKI
  • Mesh PKI
  • Single CA

Single CA

Đây là mô hình PKI cơ bản nhất phù hợp với các tổ chức nhỏ trong đó chỉ có một CA cung cấp dịch vụ cho toàn hệ thống và tất cả người dùng đặt sự tin cậy vào CA này. Mọi thực thể muốn tham gia vào PKI và xin cấp chứng chỉ đều phải thông qua CA duy nhất này. Mô hình này dễ thiết kế và triển khai nhưng cũng có các hạn chế riêng. Thứ nhất là ở khả năng co giãn – khi quy mô tổ chức được mở rộng, chỉ một CA thì khó mà quản lý và đáp ứng tốt các dịch vụ. Hạn chế thứ hai là CA này sẽ là điểm chịu lỗi duy nhất, nếu nó ngưng hoạt động thì dịch vụ bị ngưng trệ. Cuối cùng, nếu nó bị xâm hại thì nguy hại tới độ tin cậy của toàn bộ hệ thống và tất cả các chứng chỉ số phải được cấp lại một khi CA này được phục hồi.

Trust List

Nếu có nhiều CA đơn lẻ trong tổ chức nhưng lại không có các trust relationship giữa các CA được tạo ra thì bằng cách sử dụng trust list người dùng vẫn có thể tương tác với tất cả các CA. Lúc này các người dùng sẽ duy trì một danh sách các CA mà họ tin cậy. Các CA mới về sau có thể dễ dàng được thêm vào danh sách. Phương thức này tuy đơn giản nhưng cũng sẽ tốn thời gian để cập nhật hết các CA cho một lượng lớn người dùng, mặt khác nếu một CA nào đó bị thỏa hiệp thì không có một hệ thống cảnh báo nào báo cho những người dùng mà tin cậy CA đó biết được sự cố này.

Hierarchical PKI

Đây là mô hình PKI được áp dụng rộng rãi trong các tổ chức lớn. Có một CA nằm ở cấp trên cùng gọi là root CA, tất cả các CA còn lại là các Subordinate CA (gọi tắt là sub. CA) và hoạt động bên dưới root CA. Ngoại trừ root CA thì các CA còn lại trong đều có duy nhất một CA khác là cấp trên của nó. Hệ thống tên miền DNS trên Internet cũng có cấu trúc tương tự mô hình này.

Tất cả các thực thể (như người dùng, máy tính) trong tổ chức đều phải tin cậy cùng một root CA. Sau đó các trust relationship được thiết lập giữa các sub. CA và cấp trên của chúng thông qua việc CA cấp trên sẽ cấp các chứng chỉ cho các sub. CA ngay bên dưới nó. Lưu ý, root CA không trực tiếp cấp chứng chỉ số cho các thực thể mà chúng sẽ được cấp bởi các sub. CA. Các CA mới có thể được thêm ngay dưới root CA hoặc các sub. CA cấp thấp hơn để phù hợp với sự thay đổi trong cấu trúc của tổ chức. Sẽ có các mức độ tổn thương khác nhau nếu một CA nào đó trong mô hình này bị xâm hại.

Trường hợp một sub. CA bị thỏa hiệp thì CA cấp trên của nó sẽ thu hồi chứng chỉ đã cấp cho nó và chỉ khi sub. CA đó được khôi phục thì nó mới có thể cấp lại các chứng chỉ mới cho người dùng của nó. Cuối cùng, CA cấp trên sẽ cấp lại cho nó một chứng chỉ mới.

Nếu root CA bị xâm hại thì đó là một vấn đề hoàn toàn khác, toàn bộ hệ thống PKI sẽ chịu ảnh hưởng. Khi đó tất cả các thực thể cần được thông báo về sự cố và cho đến khi root CA được phục hồi và các chứng chỉ mới được cấp lại thì không một phiên truyền thông nào là an toàn cả. Vì thế, cũng như single CA, root CA phải được bảo vệ an toàn ở mức cao nhất để đảm bảo điều đó không xảy ra và thậm chí root CA có thể ở trạng thái offline – bị tắt và không được kết nối vào mạng.

Mesh PKI

Nổi lên như một sự thay thế chính cho mô hình Hierarchical PKI truyền thống, thiết kế của Mesh PKI giống với kiến trúc Web-of-Trust trong đó không có một CA nào làm root CA và các CA sẽ có vai trò ngang nhau trong việc cung cấp dịch vụ. Tất cả người dùng trong mạng lưới có thể tin cậy chỉ một CA bất kỳ, không nhất thiết hai hay nhiều người dùng phải cùng tin một CA nào đó và người dùng tin cậy CA nào thì sẽ nhận chứng chỉ do CA đó cấp

Các CA trong mô hình này sau đó sẽ cấp các chứng chỉ cho nhau. Khi hai CA cấp chứng chỉ cho nhau thì một sự tin cậy hai chiều được thiết lập giữa hai CA đó. Các CA mới có thể được thêm vào bằng cách tạo các mối tin cậy hai chiều giữa chúng với các CA còn lại trong mạng lưới.

Vì không có một CA duy nhất làm cấp cao nhất nên sự tổn hại khi tấn công vào mô hình này có khác so với hai mô hình trước đó. Hệ thống PKI không thể bị đánh sập khi chỉ một CA bị thỏa hiệp. Các CA còn lại sẽ thu hồi chứng chỉ mà chúng đã cấp cho CA bị xâm hại và chỉ khi CA đó khôi phục hoạt động thì nó mới có khả năng cấp mới các chứng chỉ cho người dùng rồi thiết lập trust với các CA còn lại trong mạng lưới.

Trong phần tiếp theo sẽ tiếp tục tìm hiểu về các khái niệm, thành phần và hoạt động của PKI.

–manthang

12 comments

  1. A cho e hỏi: khi e load các chứng thư từ Keystore windows thì danh sách các chứng thư trong usb token cũng được đọc ra nếu e cắm usb token. Khi e chọn chứng thư trong danh sách đấy trên form để ký thì nó bắt xác nhận mật khẩu của token or mật khẩu của chứng thư trong windows khi cài. Bây giờ e muốn tắt cái form xác nhận mật khẩu đấy thì làm thế nào ạ? E đọc từ keystore của PKCS11 thì nó tắt được còn từ Keystore windows thì không. Mong anh giúp e.

    1. Mình không biết Keystore Windows mà bạn nói là gì, dùng nó làm sao luôn.
      Bạn mô tả rõ hơn tìm nó ở đâu, giao diện của nó ra sao không?

      Nhưng có 1 điều là việc bạn tắt lời nhắc mật khẩu khi thực hiện việc ký số là một thói quen không nên bởi vì nếu có ai đó đánh cắp USB token của bạn thì khi đó họ không cần biết mật khẩu cũng có thể truy cập private key trong token để mạo danh bạn và thực hiện ký số.

      1. e hiểu rõ được cái đó, ý của e ở đây là nếu ng ta muốn ký nhiều nguồn dữ liệu thì mỗi lần họ ký lại phải nhập lại pass của chứng thư đó. E đang định làm lưu cái pass đó và lần sau họ ký thì sẽ không phải nhập pass nữa. E cũng kiểm tra pass khi truyền vào trong method. Nếu pass null hoặc <6 thì e cho bật dialog nhập pass và lưu cái pass đó vào biến

  2. Đây là đoạn code e đọc các chứng thư từ trong KeyStore của windows, nếu cắm token thì nó cũng load được các chứng thư trong token:
    public static Vector x509Certificate = new Vector();
    public static Vector PrivateKeyArr = new Vector();
    private char pin[] = {‘x’, ‘x’, ‘x’, ‘x’, ‘x’, ‘x’, ‘x’, ‘x’};
    String file = “name = SmartCard\n” + “library = ” + “C:/Windows/System32/PKI Token CSP/wdpkcs.dll”;
    —— đây là đọc chứng thứ trong Keystore windows —————–
    KeyStore key = KeyStore.getInstance(“Windows-MY”,”SunMSCAPI”);
    Enumeration enumer = key.aliases();
    while (enumer.hasMoreElements())
    {
    String alias = enumer.nextElement().toString();
    X509Certificate x509 = (X509Certificate) key.getCertificate(alias);
    PrivateKey pkey = (PrivateKey) key.getKey(alias,null);
    x509Certificate.add(x509);
    PrivateKeyArr.add(pkey);
    }
    —— đây là đọc chứng thứ trong Keystore PKCS11 —————–
    byte[] b = file.getBytes();
    Class sunPkcs11Class = Class.forName(“sun.security.pkcs11.SunPKCS11”);
    Constructor pkcs11Constr = sunPkcs11Class.getConstructor(java.io.InputStream.class);
    Provider pkcs11Provider = (Provider) pkcs11Constr.newInstance(new ByteArrayInputStream(b));
    Security.addProvider(pkcs11Provider);
    KeyStore key = KeyStore.getInstance(“PKCS11”);
    key.load(null,pin);
    Cái pin ở đây là mật khẩu của USB Token hoặc mật khẩu của chứng thư e cài trên máy bằng file .pfx hoặc .p12.
    Nếu e đọc kiểu này thì khi ký không phải nhập pas nữa nhưng nó lại chỉ đọc được các chứng thư trong USB Token thôi còn các chứng thư cài trong máy thì nó không load được. Mong a giúp đỡ.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s