1 .Quản lý khóa
1.1 Quản lý khóa
Giải quyết quản lý khóa với các hệ an toàn, phân phối, và lưu trữ các key. phương
pháp quản lý key An toàn là vô cùng quan trọng. Một khi một key được tạo ngẫu nhiên
nó phải được giữ bí mật để tránh rủi ro đáng tiếc (như mạo danh).Trong thực tế, hầu hết
các cuộc tấn công vào hệ thống khoá công khai có thể sẽ được nhằm vào mức quản lý
key hơn là ở các thuật toán mã hóa riêng của chính nó.
Người sử dụng phải có khả năng thu được một cặp khóa an toàn phù hợp với hiệu
quả của họ và nhu cầu bảo mật. Phải có một cách để tìm public keys của người khác và
công bố công khai public keys của riêng người đó . Người sử dụng phải có khả năng thu
được public keys hợp pháp của người khác, nếu không, một kẻ xâm nhập có thể thay đổi
public keys được liệt kê trong một thư mục, hoặc mạo nhận một người dùng khác. Việc
xác thực được sử dụng cho mục đích này Việc xác thực phải được unforgeable. Việc cấp
giấy xác thực phải tiến hành một cách an toàn, không lọt ra ngoài để tránh tấn công.
Trong thực tế, các tổ chức phát hành phải xác thực danh tính và public key của một cá
nhân trước khi ban hành giấy xác nhận cho người đó.
Nếu private key của ai đó bị mất hoặc bị tổn thất, những người khác phải được
biết về điều này, vì vậy họ sẽ không còn mã hóa các thông điệp theo public key không
hợp lệ và cũng không chấp nhận các thông điệp đã ký kết với các private key không hợp
lệ. Người sử dụng phải có khả năng lưu trữ các private key của họ một cách an toàn, vì
vậy không có kẻ xâm nhập có thể thu được chúng, nhưng các key phải sẵn sàng truy cập
để sử dụng hợp pháp. Keys cần có giá trị chỉ cho đến khi một ngày hết hạn quy định
nhưng ngày hết hạn phải được lựa chọn đúng và công bố công khai trong một kênh
chứng thực.
1.2 Tổng quan
1.2.2 Tìm một số ngẫu nhiên cho các key
Cho dù sử dụng hệ thống mật mã secret-key hay hệ thống mật mã public-key,
cũng cần một nguồn cung cấp các số ngẫu nhiên để tạo ra khóa. Một hệ thống nguồn
cung cấp tốt là nó có thể tạo ra một dãy số ko thể nào biết và đoán trước. Những chuỗi số
ngẫu nhiên thu được từ một phương pháp vật lý là tốt nhất, khi nhiều phương pháp vật lý
được áp dụng thì chuỗi số mới thực sự là ngẫu nhiên. Người ta có thể sử dụng một thiết

số mũ public, mà sau đó xác định số mũ private.

1.2.3 Vòng đời của một khóa
Các khóa có giới hạn thời gian sống cho một số lý do. Lý do quan trọng nhất là
bảo vệ chống lại giải mã mỗi lần khoá được sử dụng, nó tạo ra một số ciphertexts. Sử
dụng một khóa lập đi lập lại cho phép một kẻ tấn công xây dựng một kho lưu trữ
ciphertexts (và có thể plaintexts) có thể chứng minh đủ cho một giải mã thành công giá
trị của khóa Như vậy key cần phải có một vòng đời hạn chế. Nếu bạn nghi ngờ rằng một
kẻ tấn công có thể đã có được key của bạn,key đó phải được coi là được xâm phạm, và
việc sử dụng của nó chấm dứt.
Nghiên cứu trong phân tích mật mã có thể dẫn đến các cuộc tấn công có thể chống
lại khóa hoặc thuật toán. Ví dụ, khuyến cáo độ dài khóa RSA được tăng lên mỗi năm để
đảm bảo rằng các thuật toán được cải thiện không xâm phạm sự bảo mật của thông điệp
được mã hóa bằng RSA. Chiều dài key đề nghị phụ thuộc vào các vòng đời dự kiến của
khoá. Khóa Tạm thời , trong đó có giá trị cho một ngày hoặc ít hơn, có thể ngắn đúng 512
2
bit. Các key được sử dụng để ký hợp đồng dài hạn ví dụ, nên có độ dài 1024 bit hoặc
nhiều hơn.
Một lý do khác cho việc hạn chế vòng đời của một key là để giảm thiểu thiệt hại từ
một khóa bị tổn hại. Không chắc rằng người sử dụng sẽ phát hiện ra một kẻ tấn công đã
xâm nhập key của người đó nếu kẻ tấn công vẫn "thụ động." Tương đối thường xuyên
thay đổi key sẽ hạn chế thiệt hại tiềm ẩn từ khóa bị tổn hại. Ford [ For94 ] mô tả các chu
kỳ sống của một chìa khóa như sau:
1.Phát sinh Key và đăng ký có thể (cho một khóa công cộng).
2.Phân phối Key .
3.Kích hoạt Key / tắt và bật.
4.Thay thế key hoặc cập nhật key.
5.Thu hồi key.
6.Chấm dứt Key , liên quan đến tiêu huỷ hoặc có thể lưu trữ.
1.3 Public Key Issues

nhất định, hoặc người sử dụng.
Những nỗ lực để xác định một PKI ngày nay đang được tiến hành trong nhiều
chính phủ cũng như các tổ chức tiêu chuẩn . Cục Kho bạc của Mỹ và NIST cả hai đều có
chương trình PKI [2,3], cũng như Canada [4] và Vương quốc Anh [5]. NIST đã phát hành
một cấu hình tương tác cho các thành phần PKI [BDN97], nó xác định các thuật toán và
các định dạng chứng nhận rằng các cơ quan chứng nhận phải hỗ trợ. Một số cơ quan tiêu
chuẩn đã làm việc trên các khía cạnh PKI đã bao gồm PKIX của IETF và SPKI nhóm làm
việc [6,7] và The Open Group [8].
Hầu hết các định nghĩa PKI dựa trên chứng nhận X.509, với ngoại lệ đáng chú ý
của SPKI của IETF.
[1] PKI - PC Webopedia Định nghĩa và Liên kết:
http://webopedia.internet.com/TERM/P/PKI.html .
[2] Chính phủ Dịch vụ Công nghệ thông tin, liên bang cơ sở hạ tầng khóa công khai:
http://gits-sec.treas.gov/oofpkisteer.htm .
[3] NIST cơ sở hạ tầng khóa công khai Chương trình:
http://csrc.ncsl.nist.gov/pki/ .
[4] Chính phủ Canada chính cơ sở hạ tầng công cộng:
http://www.cse.dnd.ca/cse/english/gov.html .
[5] Tập đoàn Mở khóa công khai cơ sở hạ tầng, nhất đề xuất cho một PKI HMG.
http://www.opengroup.org/public/tech/security/pki/cki/
[6] Cơ sở hạ tầng khóa công khai (X.509) (pkix) làm việc nhóm:
http://www.ietf.org/html.charters/pkix-charter.html .
[7] Wikipedia khóa công khai cơ sở hạ tầng (spki) làm việc nhóm:
http://www.ietf.org/html.charters/spki-charter.html .
[8] Group mở khóa công khai cơ sở hạ tầng:
http://www.opengroup.org/security/pki/ .
4
1.3.2 Ai cần một cặp khoá?
Bất kỳ ai muốn đăng ký các thông điệp hoặc để nhận các thông điệp được mã hóa
phải có một cặp khóa. Mọi người có thể có nhiều hơn một cặp khoá. Trong thực tế, Được

thông điệp ký như nhau và giải mã thông điệp dành cho nhau), do đó, nói chung, khóa
riêng không nên được chia sẻ giữa người sử dụng. Tuy nhiên, một số bộ phận của một
khóa có thể được chia sẻ, tùy thuộc vào các thuật toán.
Trong RSA, trong khi mỗi người cần phải có một môđun duy nhất và số mũ riêng
(có nghĩa là, một khóa riêng duy nhất), số mũ công cộng có thể được phổ biến cho một
nhóm người dùng mà không có bảo đảm là tổn thất. Một số số mũ công trong sử dụng
5
phổ biến ngày hôm nay là 3 và 2
16
+1; bởi vì những con số này là nhỏ, các thao tác
public key (mã hóa và xác nhận chữ ký) được nhanh chóng liên quan đến các hoạt động
khóa riêng (giải mã và ký kết).Nếu một mũ công trở thành chuẩn , phần mềm và phần
cứng có thể được tối ưu hóa cho giá trị đó. Tuy nhiên, các mô đun không được chia sẻ.
Trong hệ thống khóa công dựa trên logarit rời rạc, như là Diffie-Hellman, DSA, và
ElGamal .Một nhóm người có thể chia sẻ một tập hợp các thông số hệ thống, trong đó có
thể dẫn đến việc thực hiện đơn giản hơn.Điều này cũng đúng cho các hệ thống dựa trên
đường cong elliptic logarit rời rạc. Cần lưu ý, điều này sẽ làm phá vỡ một khóa hấp dẫn
hơn để kẻ tấn công bởi vì nó có thể phá vỡ tất cả các key với một tập hợp các thông số hệ
thống với chỉ một chút nỗ lực nhiều hơn để phá vỡ một key duy nhất. Để kẻ tấn công, do
đó, chi phí trung bình để phá vỡ một key là thấp hơn rất nhiều với một tập hợp các thông
số phổ biến hơn nếu mỗi key có một bộ riêng biệt của các thông số.
Thuật toán
Diffie-Hellman
Thuật toán thỏa thuận khóa Diffie-Hellman. Giả sử A và B muốn liên lạc sử dụng
hệ mật khoá bí mật. Để thoả thuận mật khoá K chung cho cả hai bên qua một kênh không
an toàn mà không ai khác có thể biết được, A và B có thể dùng thủ tục thoả thuận khoá
Diffie -Hellman sau:
·Chọn trước một số nguyên tố p thích hợp và một phần tử sinh α của
o Z*p (2 ≤ α ≤ p-2 ) Các giá trị p và α được công khai.
·A gửi cho B giá trị α^x mod p (2.1)

một thông điệp đã ký kết với một key hết hạn. Điều này có nghĩa là khi key riêng của một
người hết hạn, tất cả mọi thứ đã ký kết với nó sẽ không còn được coi là hợp lệ. Tất nhiên,
sẽ có trường hợp, trong đó điều quan trọng là văn bản ký kết được coi là hợp lệ cho một
thời gian dài . Thảo luận về kỹ thuật số Timestamping như một cách để đạt được điều
này.
Sau khi hết hạn, key cũ cần được phá hủy để bảo vệ an ninh của các thông điệp cũ
(lưu ý, tuy nhiên, có một key hết hạn có thể cần phải được giữ lại trong một số khoảng
thời gian để giải mã thông điệp mà vẫn còn nổi bật nhưng được mã hóa trước khi hết hạn
của key). Tại thời điểm này, người sử dụng thông thường nên chọn một khóa mới, có thể
dài hơn so với khóa cũ để phản ánh cả sự gia tăng hiệu suất của phần cứng máy tính và
các cải tiến gần đây trong các thuật toán factoring .
Tuy nhiên, nếu một key đủ dài và không bị tổn hại, người sử dụng có thể tiếp tục
sử dụng cùng một key. Trong trường hợp này, cơ quan xác nhận sẽ cấp chứng nhận mới
cho cùng khóa, và tất cả các chữ ký mới sẽ chỉ vào chứng nhận mới thay vì cũ. Tuy
8
nhiên, thực tế là phần cứng máy tính tiếp tục cải thiện làm cho nó thận trọng để thay thế
các khóa hết hạn với phiên bản mới hơn, các key dài hơn mỗi vài năm. Thay thế key cho
phép tận dụng lợi thế của bất kỳ cải tiến phần cứng để tăng độ an toàn của mật mã này.
phần cứng Nhanh hơn có tác dụng bảo mật ngày càng tăng, có lẽ đáng kể, nhưng chỉ khi
độ dài key là gia tăng thường xuyên .
1.3.6 Điều gì xảy ra nếu khóa của tôi bị mất?
Nếu khóa riêng của bạn bị mất hoặc bị phá hủy nhưng không bị tổn hại, bạn có thể
không còn chữ ký hoặc thông điệp giải mã, nhưng bất cứ điều gì trước đây đã ký kết với
các key bị mất là vẫn còn giá trị. Các CA phải được thông báo ngay lập tức để key có thể
được thu hồi và được đặt trên một danh sách thu hồi chứng nhận để ngăn chặn việc sử
dụng bất hợp pháp nếu khoá được tìm thấy hoặc thu hồi bởi một đối thủ .Mất một khóa
riêng có thể xảy ra, ví dụ, nếu bạn làm mất thẻ thông minh được sử dụng để lưu trữ key
của bạn, hoặc nếu đĩa trên đó có lưu key bị hư hỏng. Bạn cũng nên có được một key mới
ngay tức thì đi để giảm thiểu số người nhắn tin gửi cho bạn được mã hóa theo khóa cũ
của bạn, vì không những có thể được đọc.

Người dùng có nhu cầu bảo mật rất cao, chẳng hạn như cơ quan xác nhận, nên sử dụng
các thiết bị chống giả mạo để bảo vệ khóa riêng của họ .
1.3.9 Làm thế nào để tìm thấy public key của một người nào khác ?
Giả sử Alice muốn tìm public key của Bob. Có một số cách có thể làm điều này.
Cô có thể gọi anh ta lên và yêu cầu anh ta phải gửi khoá công khai của mình qua e-mail.
Cô có thể yêu cầu thông qua thư điện tử, trao đổi nó trong người, cũng như cách khác. Vì
khóa công khai là công khai hiểu biết, không cần mã hóa nó trong khi chuyển nó, mặc dù
nên xác minh tính xác thực của một khóa công khai. Một sự tinh nghịch của bên thứ ba
có thể chặn việc truyền tải, thay thế key của Bob với chính mình và do đó có thể đánh
chặn và giải mã thông điệp được gửi từ Bob và Alice để mã hóa bằng khóa giả”fake”. Vì
lý do này ,một cá nhân phải xác minh key (ví dụ, điều này có thể được thực hiện bằng
cách tính toán một hash của khoá và kiểm tra nó với Bob qua điện thoại) hoặc dựa vào
các cơ quan xác nhận .cơ quan chứng nhận có thể cung cấp dịch vụ thư mục, nếu Bob
làm việc cho công ty Z, Alice có thể tìm trong thư mục lưu giữ của cơ quan xác nhận của
Z.
Hôm nay, thư mục chính thức đang nổi lên, làm on-line trang trắng hoặc màu
vàng. Cùng với T X.509 tiêu chuẩn ITU , hầu hết các thư mục chứa chứng nhận cũng như
các public keys; sự hiện diện của chứng nhận thấp hơn bảo mật của các thư mục cần
1.3.10 Chứng nhận
Chứng nhận là văn bản kỹ thuật số làm chứng cho sự ràng buộc của một khoá
công khai cho một cá nhân hoặc thực thể khác. Chúng cho phép xác minh các tuyên bố
rằng một public key đặc biệt nào trong thực tế thuộc về một cá nhân cụ thể. Chứng nhận
giúp ngăn ngừa một người nào đó sử dụng một khóa giả mạo danh người khác. Trong
một số trường hợp, nó có thể cần thiết để tạo ra một chuỗi các chứng nhận, mỗi một xác
nhận trước đó cho đến khi các bên liên quan tự tin vào nhận dạng trong câu hỏi.
Trong hình thức đơn giản của chúng, chứng nhận chứa một khóa công khai và một
tên. Như thường được sử dụng,chứng nhận cũng có ghi ngày hết hạn, tên của cơ quan xác
nhận cấp chứng nhận, một serial number, và có lẽ các thông tin khác. Quan trọng nhất, nó
có chứa các chữ ký số của người phát hành chứng nhận. Các định dạng chấp nhận rộng
rãi nhất đối với chứng chỉ được xác định bởi các X.509 tiêu chuẩn quốc tế ITU , do đó,

một hệ thống chứng nhận để người phát hành chứng nhận mức cao nhất trong chuỗi được
biết đến cho người nhận. sau đó Nếu có nhiều người nhận chứng nhận đủ nên được bao
gói để trang trải những gì mỗi người nhận có thể cần.
1.3.12 Ai phát hành các chứng nhận và bằng cách nào?
Chứng nhận được cấp bởi một cơ quan chứng nhận (CA), có thể được bất kỳ sự tin
cậy từ ban quản trị trung tâm và sẵn sàng bảo đảm cho các định dạng của những người
có nó và các vấn đề về chứng nhận, liên kết chúng với một key cho trước. Một công ty có
thể cấp chứng nhận cho nhân viên của mình, hoặc một trường đại học cho sinh viên của
mình, hay một thị trấn cho công dân của mình. Để ngăn chặn chứng nhận giả mạo, khóa
công khai của CA phải được đáng tin cậy: CA hoặc phải công khai khoá công khai của
mình hoặc cung cấp một chứng nhận từ một cấp làm chứng cao hơn CA cho những giá trị
của khoá công khai của nó. Giải pháp thứ hai đưa đến hệ thống phân cấp của CA. Xem
Hình 1 cho một ví dụ.
11
Quá trình phát hành chứng nhận như sau. Alice tạo ra cặp khóa riêng của mình và
gửi khoá công khai cho một CA thích hợp với một số bằng chứng về nhận dạng của
mình. CA kiểm tra xác định và có bất kỳ bước nào cần thiết khác để bảo đảm yêu cầu
thực sự đến từ Alice và các khóa công cộng đã không được sửa đổi trong quá cảnh, và
sau đó gửi cho cô một chứng nhận làm chứng cho sự ràng buộc giữa Alice và khoá công
khai của cô cùng với một hệ thống các chứng nhận xác nhận khóa công khai của CA.
Alice có thể đại diện chuỗi chứng nhận này bất cứ khi nào cô ấy muốn để chứng minh
tính hợp pháp của khoá công khai của mình. vì CA phải kiểm tra để xác định đúng, các tổ
chức tìm thấy nó thuận tiện để hoạt động như một CA cho các thành viên và nhân viên
của họ. Ngoài ra còn các CA cũng phát hành các chứng nhận cấp cho cá nhân không liên
kết.
Hình 1: Ví dụ về một hệ thống phân cấp cấp chứng nhận
Các CA khác nhau có thể cấp chứng nhận với cấp độ khác nhau của các yêu cầu
nhận dạng. Một CA có thể đóng dấu vào bằng lái vào CA khác có thể muốn hình thức
yêu cầu chứng nhận để được công chứng, có thể thêm một dấu vân tay của người yêu cầu
chứng nhận. Mỗi CA nên xuất bản các yêu cầu nhận dạng riêng và các tiêu chuẩn của nó,

một tin quan trọng bị mất có thể được phục hồi vào một thiết bị mới. .
1.3.14 Làm thế nào để xác nhận cơ quan dễ bị tấn công?
Một kẻ tấn công có thể cố gắng xâm nhập tìm ra private key của một CA nào đó
bằng cách đảo ngược kết cấu của thiết bị trong khi nó đã lưu trữ. Trong phiên đó, một CA
cần thật sự đề phòng để ngăn truy nhập bất hợp pháp đến private key của nó.
Key của CA có thể trở thành mục tiêu của tấn công chủ động. CAs nên dùng key
dài, và thay đổi key thường xuyên. Top level của quyền xác thực cần những key dài và
đặc biệt, có thể ko thực tế khi thay đổi thường xuyên bởi vì public key có thể viết vào
phần mềm sử dụng dãy số xác thực vô cùng lớn.
Cái gì xảy ra nếu kẻ tấn công phá được key của CA, nhưng CA sử dụng key trong
bao lâu? Mặc dù key có hiệu thực lâu, kẻ tấn công, nói A, có thể giả mạo chứng thực
trong vòng 15 ngày xác thực để giả mạo key của một người nào đó, nói B. A có thể giả
mạo tài liệu bằng chữ kí của B trong 15 ngày, có lẽ mọi thứ sẽ thoát đến A.
13
Giả sử B muốn giả mạo A, nếu B có thể thuyết phục để lấy chữ kí của A, anh ta co
thể gửi thông điệp tới ngân hàng của A và nói “ muốn rút 10k từ tài khoản của tôi. Hãy
gửi tiền cho tôi”. Cẩn thận với tấn công, B tạo 1 key giả và gửi public key đến CA nói
rằng “tôi là A. đây là public key của tôi. Hãy gửi cho tôi chứng thực”. Nếu CA bị lừa và
gửi chứng thực cho B, anh ta co thể lừa ngân hàng và hoàn thành việc tấn công. Để ngăn
chặn tấn công đó, CA cần phải kiểm tra yêu cầu chứng thực là có thực đến từ chính chủ
yêu cầu, nó cần yêu cầu chứng nhận rằng người yêu cầu chứng thực chính xác là A. ví
dụ, CA yêu cầu A xuất trình thông tin cá nhân và ngày sinh chứng thực. Một vài CA có
thể yêu cầu nhiều ID nhỏ, nhưng ngân hàng ko nên xác nhận chứng thực với một mức an
toàn thấp. Mọi CA cần phải công khai trạng thái yêu cầu ID và nguyên tắc để người khác
có thể nối kết phù hợp mức độ tin tưởng về chứng thực của mình.
Trong lần tấn công khác, B mua chuộc một vài người làm việc trong CA để họ cấp
cho anh ta 1 chứng thực mang tên A. và B có thể gửi tin nhắn có chữ kí của mang tên A
và bất kì ai nhận tin cung đều tin rằng nó đáng tin cậy bởi vì tin nhắn có kèm theo đầy đủ
và đã được kiểm chứng chuỗi xác thực. Cách tấn công này có thể bị gây trở ngại bằng
cách yêu cầu sự hợp tác của 2 (hay nhiều) nhân viên để tạo 1 chứng thực, kẻ tấn công sẽ

nhận đã được thu hồi trước ngày hết hạn dự kiến . Có nhiều lý do tại sao một giấy chứng
nhận có thể cần phải được thu hồi và được cho vào CRL. Ví dụ, khóa qui định trong
chứng thư cần được thỏa hiệp hoặc người dừng qui định trong chứng thư có thể ko còn có
quyền sử dụng key.
VD: giả sử người tên người dùng kết hợp với khóa “Alice Avery, Vice President,
Argo Corp.” nếu A bị sa thải và ko muốn cố ta sử dụng chữ kí với khóa đó nữa thì họ sẽ
thu hồi vào đặt khóa đó vào CRL
Khi xác thực chữ kí, một khảo sát về CRL liên quan đến việc đảm bảo cho chứng
thư của người kí ko bị thu hồi. Cho dù đó là giá trị thời gian để thực hiện việc kiểm tra
này phụ thuộc vào tầm quan trọng của các văn bản ký kết. Một CRL được bảo vệ bởi một
CA, và nó cung cấp thông tin về chứng thư bị thu hồi mà được ban hành bởi CA. Chỉ có
những CRL trong danh sách chứng thực hiện thời, từ khi hết hạn thì chứng thư sẽ không
được chấp nhận trong bất kì trường hợp nào: khi thu hồi các chứng thư hết hạn thì chứng
sẽ bị xóa khỏi CRL.
Những CRL thường được phân bố theo 1 trong 2 cách. Kiểu “pull”, những người
xác thực tải CRL từ CA nếu cần. Kiểu “push”, CA gửi CRL đến người xác thực trong
một khoảng nào đó một cách thường xuyên. Một số hệ thống sử dụng cách tiếp cận
hybrid mà CRL được đẩy lên một số kho trung gian từ đó ngươi xác thực có thể lấy nó
khi cần thiết
Mặc dù CRLs được bảo về theo cách thức phân phối, có thể có các kho trung tâm
cho CRL, chẳng hạn như, các trang mạng có chứa các CRLs mới nhất từ nhiều tổ chức.
Một số tổ chức như ngân hàng có thể muốn một CRL để làm cơ sở cho các tìm kiếm
CRL trên mỗi lần giao dịch khả thi hơn. Các đề xuất CRL gốc thường đòi hỏi một danh
sách, mỗi tổ chức phát hành, thu hồi các giấy chứng nhận.
15
Private-Key Information Syntax Specification Version 1.2
1.Giới thiệu:
- Thông tin private Key bao gồm một khóa riêng cho một số công chính thuật
toán và một bộ các thuộc tính. Tài liệu này cũng mô tả một cú pháp cho việc
mã hóa các private key. Một mật khẩu dựa trên thuật toán mã hóa có thể

nó là rsaEncrypttion của PKCS # 1.
• privateKey là một chuỗi octet có nội dung là những giá trị của private Key.
Việc giải thích của các nội dung được định nghĩa trong đăng ký của thuật
toán private-key. Đối với một RSA private key, ví dụ, nội dung là một mã
hóa BER của một giá trị kiểu RSAPrivateKey.
• Attributes :là một tập hợp các thuộc tính. Đây là những phần thông tin mở
rộng được mã hóa cùng với các thông tin private-key.
4.Cú pháp mã hóa thông tin Private Key :
- Mã hóa thông tin private-key sẽ có một ASN.1 kiểu EncryptedPrivateKeyInfo:
EncryptedPrivateKeyInfo ::= SEQUENCE {
encryptionAlgorithm EncryptionAlgorithmIdentifier,
encryptedData EncryptedData }
EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
EncryptedData ::= OCTET STRING
- Ý nghĩa của các trường trong kiểu EncryptedPrivateKeyInfo:
• EncryptionAlgorithm định nghĩa một thuật toán bên dưới với thông tin
private-key đã được mã hóa. 2 ví dụ là pbeWithMD2AndDES-CBC của
PKCS#5 và pbeWithMD5AndDES-CBC.
• EncryptedData cũng là một chuỗi octet và là kết quả của việc mã hóa thông
tin private – key.
- Tiến trình mã hóa có 2 bước:
1. Thông tin private-key là mã hóa BER, hiệu suất của một chuỗi octet.
2. Kết quả của bước 1 là mã hóa với một sacret key để cho ra một chuỗi octet,
kết quả của quá trình mã hóa.
5.PKCS#8 Định dạng công cụ chuyển đổi private key:
a. Tóm tắt:
openssl pkcs8 [-topk8] [-inform PEM|DER] [-outform PEM|DER] [-in
filename] [-passin arg] [-out filename] [-passout arg] [-noiter] [-nocrypt] [-
nooct] [-embed] [-nsdb] [-v2 alg] [-v1 alg] [-engine id]
b. Mô tả:

bất kỳ tùy chọn mã hóa được thiết lập sau đó là một pass phrase sẽ được yêu cầu
nhập. Các filename đầu ra không cần phải là tương tự như các filename đầu vào.
18
- passout arg
Đầu ra các file nguồn của password.

- nocrypt
\
Các khóa PKCS # 8 được tạo ra hoặc đầu vào thường PKCS # 8
EncryptedPrivateKeyInfo cấu trúc sử dụng một mật khẩu phù hợp dựa trên thuật
toán mã hóa. Với tùy chọn này một không mã hóa cấu trúc định trước
PrivateKeyInfo hoặc đầu ra. Tùy chọn này không mã hóa khóa riêng ở tất cả và
chỉ nên được sử dụng khi hình thành chuỗi octet chứa một SEQUENCE ASN1
gồm hai cấu trúc: một SEQUENCE có chứa các thông số và một ASN1
INTEGER có chứa các khóa riêng.
- Nsdb
Đây là tùy chọn tạo ra các DSA key trong một định dạng tương thích với
Netscape cơ sở dữ liệu private key. PrivateKey chứa một SEQUENCE bao gồm
các khóa public và private tương ứng.
- v2 alg
Tùy chọn này cho phép sử dụng thuật toán PKCS # 5. Bình thường PKCS # 8
private key được mã hóa bằng mật khẩu dựa trên thuật toán mã hóa được gọi là
pbeWithMD5AndDES-CBC sử dụng 56 bit DES mã hóa nhưng nó đã được các thuật
toán mã hóa mạnh hỗ trợ trong PKCS # 5 v1.5. Sử dụng tùy chọn-v2 PKCS # 5
v2.0 các thuật toán được sử dụng có thể sử dụng bất kỳ thuật toán mã hóa như 168 bit
DES ba hoặc 128 bit RC2 Tuy nhiên không nhiều người thực thi hỗ trợ PKCS # 5
v2.0. Nếu bạn chỉ sử dụng khóa riêng với OpenSSL thì điều này không quan trọng.
Các đối số ALG là thuật toán mã hóa để sử dụng, giá trị hợp lệ bao gồm des, des3 và
RC2.
- v1 alg