Chứng minh sở hữu khóa riêng trong chứng thực khóa công khai - Lê Quang Huy

Nghiên cứu khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số 34, 12- 2014 49 Chøng minh së h÷u khãa riªng trong chøng thùc khãa c«ng khai LÊ QUANG HUY, LÊ QUANG TÙNG, ĐINH PHƯỢNG TRUNG Tóm tắt: Bài báo tổng hợp về sự cần thiết và một số cách chứng minh sở hữu khóa riêng (POP- Proof of Possession) được ứng dụng trong hạ tầng khóa công khai để chứng thực tính tương ứng của một cặp khóa (công khai/riêng), đồng thời đề xuất sử dụng các hàm mật mã để đảm bảo toàn cho các cách đã nêu, và mô tả các cấu trúc dữ liệu cài đặt POP của một chuẩn cụ thể. Từ khóa: Mật mã, Hạ tầng khóa công khai, Chứng thực, Chứng minh sở hữu khóa riêng, POP. 1. MỞ ĐẦU Chứng minh sở hữu khóa riêng (Proof-of-Possession of Private Key, viết tắt là POP), là một phương tiện cung cấp một biện pháp cho một bên thứ hai thi hành một giải thuật để thiết lập một mức đảm bảo an toàn rằng bên thứ nhất sở hữu và có khả năng sử dụng khóa riêng. POP là một thao tác cần thiết được sử dụng trong hạ tầng khóa công khai (PKI) để một thực thể cuối (EE) có thể chứng minh với CA/RA rằng nó sở hữu khóa riêng tương ứng với khóa công khai yêu cầu chứng thực. Nói một cách khác POP đảm bảo với CA/RA rằng thực thể cuối mà yêu cầu chứng thực khóa công khai Y thực sự sở hữu khóa riêng X tương ứng. Trong PKI, POP được triển khai (cài đặt) trong các yêu cầu (PKI request), cụ thể là trong thông điệp yêu cầu chứng thực (Certificate Request Message), để thực thể cuối chứng minh sở hữu khóa riêng với CA/RA. POP được thực hiện theo nhiều cách phụ thuộc vào mục đích sử dụng của khóa. POP cung cấp thêm mức đảm bảo an toàn cho hoạt động của PKI, nó cho phép CA/RA kiểm tra được sự gắn kết giữa một thực thể và cặp khóa của nó (xác thực được thông tin yêu cầu chứng thực) và nhằm ngăn chặn các tấn công (nguy cơ) đối với các mục đích sử dụng của khóa. 2. MỘT SỐ QUY ƯỚC EE: Thực thể cuối. EEName : tên của EE. CA: Thẩm quyền chứng thực. RA: Thẩm quyền đăng ký. EEpub, EEpri : lần lượt là khóa công khai và khóa riêng của EE. ( ) pubEE Sign Text : Ký số lên Text bằng khóa riêng của EE. ( ) pubEE Ver Z : Kiểm tra chữ ký bằng khóa công khai của EE. EncK(Text): mã mật giá trị Text sử dụng lược đồ mật mã đối xứng với khóa bí mật K. DecK(Z): giải mã giá trị Z sử dụng lược đồ mật mã đối xứng với khóa bí mật K. ( ) pubRA Enc Text : mã mật giá trị Text sử dụng lược đồ mật mã khóa công khai với khóa công khai RApub. ( ) priRA Dec Z : giải mã mật giá trị Z sử dụng lược đồ mật mã khóa công khai với khóa riêng RApri. Kỹ thuật điện tử & Khoa học máy tính L. Q. Huy, L. Q. Tùng, Đ. P. Trung, “Chứng minh sở hữu khóa riêng khóa công khai.” 50 Nonce: giá trị ngẫu nhiên. Comp(A, A’): so sánh giữa A và A’. Hash(m): băm thông điệp dữ liệu m. Req(EEpub): gửi yêu cầu chứng thực tới CA/RA với tham số khóa công khai EEpub. KDF(m): Dẫn xuất khóa từ tham số m. KWK(X); )( 1 YKWK  : Bọc khóa X bằng khóa K; giải bọc khóa Y bằng khóa K. MACK(text): Tóm lược thông điệp dữ liệu m với khóa K. 3. GIAO THỨC CHỨNG MINH SỞ HỮU KHÓA RIÊNG Giao thức chứng minh sở hữu khóa riêng – giao thức POP bao gồm các thông điệp dữ liệu (PKI Message) cần thiết để một thực thể cuối có thể chứng minh với CA/RA rằng nó sở hữu khóa riêng tương ứng với khóa công khai được yêu cầu chứng thực. POP được ứng dụng trong giao thức quản lý chứng thư. Để thực hiện POP người ta sử dụng nhiều cách khác nhau phụ thuộc vào mục đích sử dụng của cặp khóa yêu cầu chứng thực. Có 3 trường hợp thực hiện POP tương ứng với 3 mục đích sử dụng khóa: dùng để ký, để mã, để thỏa thuận khóa. 3.1. Với các khóa dùng để ký Nếu không sử dụng POP, chủ sở hữu cặp khóa ký có nguy cơ bị mạo danh chữ ký (mục 5.1 trong [5]). Khi A gửi yêu cầu chứng thực, B tấn công thay khóa công khai của A bằng khóa công khai của mình trong yêu cầu chứng thực. Sau khi được cấp chứng thư (tên là A, khóa công khai của B), B sử dụng khóa riêng để ký và gửi cho C, C sử dụng chứng thư nêu trên (tên của A) kiểm tra thấy hợp lệ và tin rằng A đã ký lên tài liệu này. Với cặp khóa dùng để ký (mục 4.3.1 trong [1]), thực thể cuối có thể chứng minh sở hữu khóa riêng bằng cách ký lên một giá trị. Các bước thực hiện như sau: 1. Thực thể cuối ký lên giá trị bao gồm thông tin về tên và khóa công khai của thực thể cuối. Thông tin về tên, khóa công khai và chữ ký được kèm theo trong yêu cầu chứng thực. 2. CA/RA sẽ sử dụng khóa công khai trong yêu cầu chứng thực để kiểm tra chữ ký. Nếu đúng thì khẳng định rằng thực thể yêu cầu chứng thực khóa công khai sở hữu khóa riêng tương ứng. Tóm tắt các bước: EE CA/RA 1 ( || ) priEE name pub Z Sign EE EE Z, EEpub 2 ( ) pubEE Ver Z 3.2. Với các khóa dùng để mã Nếu không sử dụng POP, chủ sở hữu cặp khóa mã phải đối mặt với nguy cơ bị lộ thông tin (mục 5.1 trong [5]). Nguy cơ này cũng tương tự như trường hợp đối với khóa dùng để ký, xảy ra khi bị tấn công thay khóa công khai trong yêu cầu chứng thực. Khi đó nếu có một tài liệu mật, C mã mật và gửi cho A thì B sẽ có khả năng giải mã mật được tài liệu đó. Với cặp khóa dùng để mã, có 3 cách chứng minh sở hữu khóa riêng: Gửi khóa riêng (có bọc), cách trực tiếp và cách gián tiếp (mục 4.3.2 trong [1]). Nghiên cứu khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số 34, 12- 2014 51 Đối với cách trực tiếp hoặc gián tiếp việc chứng minh sở hữu khóa riêng được thực hiện bằng cách yêu cầu thực thể cuối giải mã mật một giá trị xác định. 3.2.1. Cách gửi khóa riêng có bọc Với cách gửi khóa riêng có bọc: Thực thể cuối gửi cả khóa riêng và khóa công khai tới CA/RA trong yêu cầu chứng thực (mục 5.2.8.1. trong [1]). Các bước thực hiện như sau: 1. Thực thể cuối bọc khóa riêng (mã bằng mã pháp đối xứng) và gửi kèm theo yêu cầu. 2. CA/RA sẽ giải bọc khóa riêng và kiểm tra sự phù hợp giữa khóa riêng với khóa công khai (bằng cách ký lên một giá trị bất kỳ và kiểm tra chữ ký). Nếu kiểm tra đúng sẽ khẳng định thực thể yêu cầu chứng thực khóa công khai sở hữu khóa riêng tương ứng. Cách này chỉ áp dụng đối với khóa mã được thực thể cuối sinh ra cần được lưu trữ lâu dài và khôi phục về sau. EEpri là khóa riêng dùng để mã. Tóm tắt các bước: EE CA/RA 1 Sinh khóa K ngẫu nhiên Z = KWK(EEpri) Z, X 2 ; )(1 ZKWEE Kpri  ( ( )) pub priEE EE Ver Sign nonce 3.2.2. Cách trực tiếp Cách trực tiếp sử dụng một giao thức kiểu Challenge-Response (mục 5.2.8.3 trong [1]). Giao thức Challenge-Response là giao thức xác thực sở hữu khóa riêng dựa trên việc giải mã mật (bằng khóa công khai) một giá trị ngẫu nhiên và một bằng chứng (mục 10.3.3 trong [4]). Cách này được sử dụng trong môi trường PKI để RA trực tiếp xác minh sở hữu khóa riêng đối với thực thể cuối, và yêu cầu thực thể cuối ngay lập tức đáp lại các thông điệp dữ liệu (message) của RA. Vì EE phải ngay lập tức đáp lại RA nên cách này cần phải được thực hiện trực tuyến (online). Nếu xác thực thành công RA sẽ đại diện cho EE gửi yêu cầu chứng thực tới CA. Giao thức Challenge-Response này được thực hiện như sau: 1. Thực thể cuối gửi yêu cầu chứng thực khóa công khai tới RA. 2. RA chọn ngẫu nhiên giá trị r, tính toán bằng chứng x = H(r) (x thể hiện tri thức về r mà không bộc lộ r). RA tính giá trị challenge ( , ) pubEE name c Enc r RA (mã mật giá trị ngẫu nhiên và định danh của mình bằng khóa công khai EEpub), rồi gửi tới EE bộ (x = H(r), c) với ( , ) pubEE name c Enc r RA . 3. EE sử dụng khóa riêng của mình để giải mã giá trị c nhằm khôi phục ra r’ và RAname’, tính giá trị x’ = H(r’). So sánh x và x’ (kiểm tra toàn vẹn) nếu bằng nhau thì gửi giá trị r’ tới RA. 4. RA so sánh giá trị r với r’. Nếu bằng nhau thì RA đã xác thực một chiều được EE và EE đã chứng minh với RA rằng nó sở hữu khóa riêng. Tóm tắt các bước: Kỹ thuật điện tử & Khoa học máy tính L. Q. Huy, L. Q. Tùng, Đ. P. Trung, “Chứng minh sở hữu khóa riêng khóa công khai.” 52 EE RA 1 Sinh cặp khóa EEpub, EEpri EEpub 2 x, c r=nonce; x = H(r); ( , ) pubEE name c Enc r RA 3 )(, cDecr priEE  ; x’=H(r’) Comp(x’, x); r’ 4 Comp(r’, r) 3.2.3. Cách gián tiếp Cách gián tiếp yêu cầu thực thể cuối chứng minh sở hữu khóa riêng bằng cách giải mã mật một giá trị (mục 5.2.8.2 trong [1]). Trong cách này CA mã mật một giá trị theo cách chỉ duy nhất thực thể cuối yêu cầu có thể giải mã mật được. Cụm từ gián tiếp có nghĩa rằng CA sẽ thực hiện việc xác thực sở hữu khóa riêng của EE, RA chỉ đóng vai trò trung gian chuyển yêu cầu (CA gián tiếp xác thực EE qua RA). Cách này có thể thực hiện ngoại tuyến (offline). Các bước thực hiện như sau: 1. Thực thể cuối gửi yêu cầu chứng thực tới CA. 2. CA gửi đáp lại thực thể cuối một giá trị dữ liệu đã mã mật bằng khóa phiên (do CA sinh ngẫu nhiên) bởi mã pháp đối xứng và đến lượt khóa phiên được mã mật bởi khóa công khai của thực thể cuối. Giá trị dữ liệu này có thể là chứng thư của thực thể cuối do CA phát hành. 3. Thực thể cuối nắm giữ khóa riêng tương ứng sẽ giải mã mật giá trị nhận được từ CA và tạo ra giá trị băm của giá trị đó, CertHash, rồi gửi lại CA. 4. CA sẽ băm giá trị ban đầu và so sánh với giá trị m = CertHash nhận được, nếu bằng nhau thì khẳng định rằng thực thể cuối có quyền truy nhập đến khóa riêng tương ứng. Tóm tắt các bước thực hiện: EE CA 1 Sinh cặp khóa EEpub, EEpri EEpub 2 Sinh khóa K ngẫu nhiên; m = CertEE; x, y x = EncK(m); ( ) pubEE y Enc K ; 3 );(' yDecK priEE  m’ = DecK’(x); n’ = H(m’); n’ 4 Comp(n’, n = H(m)). 3.3. Với các khóa dùng để thỏa thuận khóa Với khóa dùng để thiết lập khóa (mục 3.1 trong [6]) (trao đổi hay thỏa thuận khóa, hay vận chuyển khóa), nếu không có POP, quá trình thiết lập khóa có thể phải đối mặt với một số tấn công, điển hình là tấn công chia sẽ khóa không biết (Unknown Key Share attack) trong quá trình thỏa thuận khóa. Nghiên cứu khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số 34, 12- 2014 53 POP với các khóa dùng để thỏa thuận khóa có thể dùng bốn cách (mục 4.3.2 trong [1]). Ba cách đầu cũng giống như đối với khóa dùng để mã (cặp khóa dùng để thỏa thuận khóa được chứng minh sở hữu khóa riêng theo các cách giống như cặp khóa dùng để mã). Cách thứ tư: thực thể cuối chứng minh sở hữu khóa riêng dựa trên bài toán logarit rời rạc trong nhóm GF(p) hoặc trong nhóm các điểm trên đường cong elliptic. Có nhiều giao thức thỏa thuận khóa dựa trên kiểu Diffie-Hellman trên nhóm GP(p) (hoặc tương tự trên nhóm các điểm đường cong elliptic). Phần sau sẽ mô tả giao thức POP cho trường hợp nhóm cơ sở là GF(p), nó sử dụng một hàm dẫn xuất khóa (KDF – Key Derivarion Function) và một hàm tóm lược thông báo có khóa (MAC – Message Authentication Code). 1. Tham số chung Thực thể cuối EE và CA/RA có chung các tham số g, p. Số p nguyên tố (sao cho bài toán tính logarit rời rạc trên GF(p) là bài toán khó) và g là phần tử sinh của GF(p). 2. EE thực hiện các bước sau: 2.1 Sinh khóa riêng của EE, y =EEpri. Tính khóa công khai EEpub= g y mod p; 2.2 Lấy khóa công khai của CA/RA (CA/RApub) trong chứng thư của CA/RA; 2.3 Tính giá trị bí mật chung: ZZ = (CA/RApub) y mod p; 2.4 Tính khóa K được dẫn xuất từ giá trị bí mật ZZ : K = KDF(LI ||ZZ||TI); LI = EE Distinguished Name; TI = CA/RA Distinguished Name; LI (Leading Information), TI (Trailing Information); 2.5 Tính giá trị m = MACK(text); text = certificationRequestInfo; 2.6 Gửi giá trị m trong request tới CA/RA; (trong request có thông tin về các hàm KDF, MAC, LI, TI ); 3. CA/RA thực hiện các bước sau: Ký hiệu x là khóa riêng của CA/RA, x= CA/RApri. Khi đó khóa công khai CA/RApub = g x mod p. 3.1 Tính giá trị bí mật chung: ZZ’ = (EEpub) x mod p; EEpub có trong yêu cầu; 3.2 Tính khóa tạm K’ được dẫn xuất từ bí mật chung ZZ’; K’ = KDF(LI ||ZZ’||TI); 3.3 Tính giá trị m’ = MACK’(text); 3.4 So sánh m và m’: Nếu m = m’ thì kết luận rằng EE sở hữu khóa riêng (trong hệ mật khóa công khai dựa trên độ khó của bài toán tính logarit rời rạc) (là y) tương ứng với khóa công khai EEpub mà EE yêu cầu CA/RA chứng thực. Chỉ CA/RA mà EE gửi yêu cầu tới có thể kiểm tra được sự phù hợp giữa khóa riêng và khóa công khai của EE vì nó sở hữu khóa riêng x để tính ra giá trị bí mật chung. Tóm tắt các bước như sau: EE CA/RA 1 y=EEpri, EEpub = g y mod p; ZZ = (CA/RApub) y mod p; LI = EE Distinguished Name; TI = CA/RA Distinguished Name; K = KDF(LI ||ZZ||TI); Kỹ thuật điện tử & Khoa học máy tính L. Q. Huy, L. Q. Tùng, Đ. P. Trung, “Chứng minh sở hữu khóa riêng khóa công khai.” 54 text = certificationRequestInfo; m = MACK(text); m, EEpub 2 x= CA/RApri; CA/RApub = g x mod p ZZ’ = (EEpub) x mod p; K’ = KDF(LI ||ZZ’||TI); m’ = MACK’(text); Comp(m’, m). 4. CẤU TRÚC DỮ LIỆU MÔ TẢ GIAO THỨC POP Để có thể ứng dụng rộng rãi POP trong các phần mềm PKI, một số tổ chức đã đưa ra các khuyến cáo, đặc tả, định chuẩn về POP trong giao thức trao đổi thông điệp dữ liệu giữa các thành phần của PKI. Hiện nay đã có một số đặc tả, chuẩn về POP cho PKI được công bố như: - PKCS #10 [7] của RSA Laboratories. - Đặc tả Wireless PKI [8], của Open Mobile Alliance. - Đặc tả về CMP [1] của IETF. Trong các đặc tả trên, phần mô tả POP trong CMP của IETF sử dụng cấu trúc thông điệp dữ liệu mật mã ([9], [10]) có ứng dụng rộng rãi nhất và được sử dụng trong nhiều phần mềm PKI hiện hành. Sau đây sẽ trình bày một số cấu trúc dữ liệu mô tả POP trong đặc tả CMP của IETF. 4.1. Cấu trúc thông điệp dữ liệu PKI Cấu trúc tổng thể thông điệp dữ liệu PKI (mục 5 trong [1]): 1. PKI Message PKIMessage ::= SEQUENCE { header PKIHeader, // tiêu đề chứa thông tin chung body PKIBody, // chứa thông tin cụ thể của mỗi thông điệp protection [0] PKIProtection OPTIONAL, // bảo vệ tính toàn vẹn extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL //các chứng thư đính kèm nếu có} PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 2. PKI Message Header PKIHeader ::= SEQUENCE { pvno INTEGER { cmp1999(1), cmp2000(2) }, sender GeneralName, recipient GeneralName, messageTime [0] GeneralizedTime OPTIONAL, protectionAlg [1] AlgorithmIdentifier OPTIONAL, generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL} PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String PKI Header chứa các thông tin nhằm xác định địa chỉ và nhận dạng giao dịch. Các thông tin này được bảo vệ toàn vẹn. 3. PKI Message Body PKIBody ::= CHOICE { ir [0] CertReqMessages, --Initialization Req ip [1] CertRepMessage, --Initialization Resp cr [2] CertReqMessages, --Certification Req Nghiên cứu khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số 34, 12- 2014 55 cp [3] CertRepMessage, --Certification Resp p10cr [4] CertificationRequest, --PKCS #10 Cert. Req. popdecc [5] POPODecKeyChallContent --pop Challenge popdecr [6] POPODecKeyRespContent, --pop Response pollReq [25] PollReqContent, --Polling request pollRep [26] PollRepContent --Polling response } PKI body chứa 1 trong 26 loại dữ liệu trên. 4. PKI Message Protection Một số PKI message cần được bảo vệ toàn vẹn sử dụng giải thuật mật mã bất đối xứng với cấu trúc có dạng sau: PKIProtection ::= BIT STRING Trường protectionAlg trong phần PKI header phải được thiết lập nhằm xác định giải thuật được sử dụng để bảo vệ thông điệp dữ liệu. Đầu vào của trường protection (PKIProtection) là ProtectedPart ProtectedPart ::= SEQUENCE { header PKIHeader, body PKIBody } Tùy từng trường hợp trường PKIProtection có thể chứa MAC hoặc chữ ký số. 4.2. Cấu trúc POP 4.2.1. Vị trí của POP POP được cài đặt trong Certificate request theo cấu trúc sau: (mục 3 trong [2]). 1. Certificate request message Certificate request message chứa các thông tin về yêu cầu chứng thực CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg CertReqMsg ::= SEQUENCE { certReq CertRequest, // mẫu chứng thư được yêu cầu popo ProofOfPossession OPTIONAL, //giá trị để chứng minh khóa riêng regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL //các thông tin bổ sung phụ thuộc vào ngữ cảnh của mỗi yêu cầu chứng thực} 2. Proof Of Possession ProofOfPossession chứa các thông tin được sử dụng để chứng minh khóa riêng. ProofOfPossession ::= CHOICE { raVerified [0] NULL, //RA đã thực hiện POP thay CA signature [1] POPOSigningKey, // thực hiện POP với các khóa để ký keyEncipherment [2] POPOPrivKey, //thực hiện POP với các khóa dùng để mã keyAgreement [3] POPOPrivKey //POP với các khóa thỏa thuận khóa } (mục 4 trong [2]). 4.2.2. Với các khóa để ký Cấu trúc dữ liệu chứa thông tin về khóa để ký gồm (mục 4.1 trong [2]): POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, // chứa dữ liệu sẽ được ký algorithmIdentifier AlgorithmIdentifier, // định danh giải thuật ký signature BIT STRING // chứa giá trị POP } Các trường của kiểu POPOSigningKeyInput gồm:. POPOSigningKeyInput ::= SEQUENCE { Kỹ thuật điện tử & Khoa học máy tính L. Q. Huy, L. Q. Tùng, Đ. P. Trung, “Chứng minh sở hữu khóa riêng khóa công khai.” 56 authInfo CHOICE { sender [0] GeneralName, // thông tin về người ký publicKeyMAC PKMACValue // khóa công khai của người ký }, publicKey SubjectPublicKeyInfo } Các trường của kiểu PKMACValue có nghĩa sau: PKMACValue ::= SEQUENCE { algId AlgorithmIdentifier, // định danh giải thuật để tính giá trị MAC value BIT STRING // giá trị MAC } 4.2.3. Với các khóa để mã Cấu trúc thông tin về khóa mã (mục 4.2 trong [2]): POPOPrivKey ::= CHOICE { - thisMessage [0] BIT STRING, -- deprecated // phản đối sử dụng subsequentMessage [1] SubsequentMessage,//phươngpháp trực tiếp,gián tiếp - dhMAC [2] BIT STRING, -- deprecated // phản đối sử dụng agreeMAC [3] PKMACValue, // POP với khóa thỏa thuận khóa encryptedKey [4] EnvelopedData // gửi khóa riêng có bọc } Cấu trúc kiểu SubsequentMessage: SubsequentMessage ::= INTEGER { encrCert (0), // chứng thư đã phát hành được mã - cách gián tiếp challengeResp (1) // cách thách thức - cách trực tiếp } POPODecKeyChallContent ::= SEQUENCE OF Challenge Challenge ::= SEQUENCE { owf AlgorithmIdentifier OPTIONAL, witness OCTET STRING, challenge OCTET STRING } POPODecKeyRespContent ::= SEQUENCE OF INTEGER 4.2.4. Với các khóa thỏa thuận khóa Cấu trúc thông tin chứa các trường PKMACValue gồm (mục 4.1 trong [3]): PKMACValue ::= SEQUENCE { algId AlgorithmIdentifier, // định danh giải thuật (ký, tóm lược) value BIT STRING // giá trị ký, tóm lược } DhSigStatic ::= SEQUENCE { issuerAndSerial IssuerAndSerialNumber OPTIONAL, hashValue MessageDigest} 5. MỘT VÀI ĐỀ XUẤT ĐẢM BẢO AN TOÀN 5.1. POP với khóa dùng để ký Đối với cặp khóa dùng để ký, độ an toàn của giao thức POP phụ thuộc vào nhiều yếu tố trong đó quan trọng nhất là thuật toán ký. Một số thuật toán ký an toàn nên được cài đặt như RSA-SSA-PSS với các tham số an toàn (độ dài khóa ≥ 2048 bit) (mục 8 trong [14]), ECDSA với các tham số an toàn (độ dài khóa ≥ 256 bit) (mục 6 trong [16]). 5.2. POP với khóa dùng để mã 5.2.1. Cách gửi khóa riêng có bọc Với cách chứng minh sở hữu khóa riêng thông qua việc gửi khóa riêng tới CA/RA có thể mang đến một số rủi ro về an toàn (tồn tại khả năng bị đánh cắp Nghiên cứu khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số 34, 12- 2014 57 khóa riêng khi giải bọc, lưu trữ) (mục 8.2 trong [1]). Do đó chỉ áp dụng trường hợp này khi người dùng, ứng dụng hoàn toàn tin cậy vào CA/RA. Bên cạnh đó độ an toàn của POP phụ thuộc vào độ an toàn của thuật toán bọc khóa. Một số thuật toán bọc khóa an toàn như AESKW với các tham số an toàn (độ dài khóa ≥ 256 bit), TDKW ([11], [12]), . 5.2.2. Cách trực tiếp và gián tiếp Độ an toàn của các cách này phụ thuộc vào các lược đồ mật mã khóa công khai và các hàm băm. Một số thuật toán mật mã khóa công khai an toàn nên được cài đặt như RSA-ES-OAEP với các tham số an toàn (độ dài khóa ≥ 2048 bit), ECIES với các tham số an toàn (độ dài khóa ≥ 256 bit). Một số hàm băm an toàn nên được cài đặt như SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256); SHA-3(224, 256, 384, 512) [15]. 5.3. POP với khóa dùng để thỏa thuận khóa Với cặp khóa dùng để thỏa thuận khóa (mục 2.3.) có thể phải đối mặt với một số tấn công như: tấn công nhóm nhỏ, tấn công xen giữa (man-in-the-middle attacks), tấn công chia sẽ khóa không biết (Unknown Key-Share Attack) [6] Độ an toàn phụ thuộc vào độ an toàn của các hàm dẫn xuất khóa và các hàm tóm lược thông báo. Hàm KDF an toàn nên được sử dụng là PBKDF2 [13] với các tham số an toàn như giá trị salt ít nhất 128 bit, hàm giả ngẫu nhiên sử dụng hàm thuộc họ SHA hoặc AES. Một số hàm MAC có khóa an toàn nên được sử dụng như HMAC (SHA1, SHA256). Một số lược đồ trao đổi khóa an toàn dựa trên các giao thức họ Diffie-Hellman nên được sử dụng như MQV, ECMQV, ... 6. KẾT LUẬN Chứng minh sở hữu khóa riêng là một thao tác cần thiết và phải được áp dụng trong PKI. Sử dụng POP sẽ nâng cao độ an toàn và tin cậy cho các hoạt động của hệ thống PKI nhất là thao tác chứng thực khóa công khai. Có 3 trường hợp chứng minh sở hữu khóa riêng có thể được sử dụng căn cứ vào mục đích sử dụng của cặp khóa. Để đảm bảo an toàn cho giao thức POP đề xuất sử dụng trong giao thức tương ứng với mỗi cách POP cụ thể. Bài báo cũng trình bày chuẩn về POP trong CMP của IETF được sử dụng rộng rãi trong nhiều phần mềm PKI hiện hành. Bên cạnh những nội dung đã trình bày, một số vấn đề cần tiếp tục nghiên cứu thêm như: khả năng sử dụng nhiều cách POP cho một cặp khóa, ứng dụng POP trong một số hệ thống PKI hiện hành và đánh giá an toàn khi sử dụng POP trong những hệ thống đó. TÀI LIỆU THAM KHẢO [1]. IETF, RFC 4210, “Certificate Management Protocol (CMP)”, 2005, https://tools.ietf.org/html/rfc4210. [2]. IETF, RFC 4211, “Certificate Request Message Format (CRMF)”, 2005, https://tools.ietf.org/html/rfc4211. [3]. IETF, RFC 6955, “Diffie-Hellman Proof-of-Possession Algorithms”, 2013, https://tools.ietf.org/html/rfc6955. [4]. B. C. Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook of Applied Cryptography", CRC Press ISBN 0-8493-8523-7, 1996. [5]. B N. Asokan, Valtteri Niemi, Pekka Laitinen, “On the usefulness of proof-of- Kỹ thuật điện tử & Khoa học máy tính L. Q. Huy, L. Q. Tùng, Đ. P. Trung, “Chứng minh sở hữu khóa riêng khóa công khai.” 58 possession”, 2nd Annual PKI Research Workshop---Pre-Proceeding. [6]. Simon Blake-Wilson and Alfred Menezes, “Unknown Key-Share Attack on the Station-to-Station (STS) Protocol”, Public Key Cryptography, Lecture Notes in Computer Science, 1560, 1999, pp. 154–170. [7]. RSA Laboratories, PKCS #10 v1.7:, “Certification Request Syntax Standard”, RSA Laboratories, May 2000. [8]. WAP Forum, “Wireless application protocol, public key infrastrcutre definition”, WAP forum, WAP-217-WPKI, April 2001. [9]. IETF, RFC 5652, “Cryptographic Message Syntax (CMS)”, 2009, https://tools.ietf.org/html/rfc5652. [10]. IETF, RFC 5272, “Certificate Management over CMS (CMC)”, 2008, https://tools.ietf.org/html/rfc5272. [11]. IETF, RFC 3394, “Advanced Encryption Standard (AES) Key Wrap Algorithm”, 2002, https://tools.ietf.org/html/rfc3394. [12]. IETF, RFC 3217, “Triple-DES and RC2 Key Wrapping”, 2001, https://tools.ietf.org/html/rfc3217. [13]. IETF, RFC 2898, “PKCS #5: Password-Based Cryptography Specification Version 2.0”, 2000, https://tools.ietf.org/html/rfc2898. [14]. RSA laboratories, “PKCS#1 v2.2 RSA Cryptography Standard”, 2012, cryptography-standard-wp.pdf [15]. FIPS PUB 180-4, Secure Hash Standard (SHS), 2012, [16] FIPS PUB 186-3, Digital Signature Standard (DSS), 2009, ABSTRACT PROOF OF POSSESION OF PRIVATE KEY IN PUBLIC KEY CERTIFICATION This paper summarizes the need and several ways for Proof-of-Possession of Private Key used in Public Key Infrastructure for verifying key pair match (public/private). The paper has also recommended for using some cryptographic functions to secure these POP methods and has presented POP data structures of a specific standard. Keywords: Cryptography, Public key infrastructure, Certification, Proof-of-possession private key, POP. Nhận bài ngày 19 tháng 3 năm 2014 Hoàn thiện ngày 15 tháng 6 năm 2014 Chấp nhận đăng ngày 05 tháng 12 năm 2014 Địa chỉ: Ban Cơ yếu Chính phủ; email: lequanghuy@ca.gov.vn; điện thoại: 0918491930.