PKCS

PKCS 全称是 Public-Key Cryptography Standards ，是由 RSA 实验室与其它安全系统开发商为促进公钥密码的发展而制订的一系列标准。

What is PKCS? http://www.rsa.com/rsalabs/node.asp?id=2308

PKCS 目前共发布过 15 个标准：
（1）PKCS#1：RSA加密标准。PKCS#1定义了RSA公钥函数的基本格式标准，特别是数字签名。它定义了数字签名如何计算，包括待签名数据和签名本身的格式；它也定义了PSA公/私钥的语法。

（2）PKCS#2：涉及了RSA的消息摘要加密，这已被并入PKCS#1中。

（3）PKCS#3：Diffie-Hellman密钥协议标准。PKCS#3描述了一种实现Diffie- Hellman密钥协议的方法。

（4）PKCS#4：最初是规定RSA密钥语法的，现已经被包含进PKCS#1中。

（5）PKCS#5：基于口令的加密标准。PKCS#5描述了使用由口令生成的密钥来加密8位位组串并产生一个加密的8位位组串的方法。PKCS#5可以用于加密私钥，以便于密钥的安全传输（这在PKCS#8中描述）。

（6）PKCS#6：扩展证书语法标准。PKCS#6定义了提供附加实体信息的X.509证书属性扩展的语法（当PKCS#6第一次发布时，X.509还不支持扩展。这些扩展因此被包括在X.509中）。

（7）PKCS#7：密码消息语法标准。PKCS#7为使用密码算法的数据规定了通用语法，比如数字签名和数字信封。PKCS#7提供了许多格式选项，包括未加密或签名的格式化消息、已封装（加密）消息、已签名消息和既经过签名又经过加密的消息。

（8）PKCS#8：私钥信息语法标准。PKCS#8定义了私钥信息语法和加密私钥语法，其中私钥加密使用了PKCS#5标准。

（9）PKCS#9：可选属性类型。PKCS#9定义了PKCS#6扩展证书、PKCS#7数字签名消息、PKCS#8私钥信息和PKCS#10证书签名请求中要用到的可选属性类型。已定义的证书属性包括E-mail地址、无格式姓名、内容类型、消息摘要、签名时间、签名副本（counter signature）、质询口令字和扩展证书属性。

（10）PKCS#10：证书请求语法标准。PKCS#10定义了证书请求的语法。证书请求包含了一个唯一识别名、公钥和可选的一组属性，它们一起被请求证书的实体签名（证书管理协议中的PKIX证书请求消息就是一个PKCS#10）。

（11）PKCS#11：密码令牌接口标准。PKCS#11或“Cryptoki”为拥有密码信息（如加密密钥和证书）和执行密码学函数的单用户设备定义了一个应用程序接口（API）。智能卡就是实现Cryptoki的典型设备。注意：Cryptoki定义了密码函数接口，但并未指明设备具体如何实现这些函数。而且Cryptoki只说明了密码接口，并未定义对设备来说可能有用的其他接口，如访问设备的文件系统接口。

（12）PKCS#12：个人信息交换语法标准。PKCS#12定义了个人身份信息（包括私钥、证书、各种秘密和扩展字段）的格式。PKCS#12有助于传输证书及对应的私钥，于是用户可以在不同设备间移动他们的个人身份信息。

（13）PDCS#13：椭圆曲线密码标准。PKCS#13标准当前正在完善之中。它包括椭圆曲线参数的生成和验证、密钥生成和验证、数字签名和公钥加密，还有密钥协定，以及参数、密钥和方案标识的ASN.1语法。

（14）PKCS#14：伪随机数产生标准。PKCS#14标准当前正在完善之中。为什么随机数生成也需要建立自己的标准呢？PKI中用到的许多基本的密码学函数，如密钥生成和Diffie-Hellman共享密钥协商，都需要使用随机数。然而，如果“随机数”不是随机的，而是取自一个可预测的取值集合，那么密码学函数就不再是绝对安全了，因为它的取值被限于一个缩小了的值域中。因此，安全伪随机数的生成对于PKI的安全极为关键。

（15）PKCS#15：密码令牌信息语法标准。PKCS#15通过定义令牌上存储的密码对象的通用格式来增进密码令牌的互操作性。在实现PKCS#15的设备上存储的数据对于使用该设备的所有应用程序来说都是一样的，尽管实际上在内部实现时可能所用的格式不同。PKCS#15的实现扮演了翻译家的角色，它在卡的内部格式与应用程序支持的数据格式间进行转换。

X509

X.509是常见通用的证书格式。所有的证书都符合为Public Key Infrastructure (PKI) 制定的 ITU-T X509 国际标准。X.509是国际电信联盟-电信（ITU-T）部分标准和国际标准化组织（ISO）的证书格式标准。作为ITU-ISO目录服务系列标准的一部分，X.509是定义了公钥证书结构的基本标准。1988年首次发布，1993年和1996年两次修订。当前使用的版本是X.509 V3，它加入了扩展字段支持，这极大地增进了证书的灵活性。X.509 V3证书包括一组按预定义顺序排列的强制字段，还有可选扩展字段，即使在强制字段中，X.509证书也允许很大的灵活性，因为它为大多数字段提供了多种编码方案.

PKCS#7 常用的后缀是： .P7B .P7C .SPC
PKCS#12 常用的后缀有： .P12 .PFX
X.509 DER 编码(ASCII)的后缀是： .DER .CER .CRT
X.509 PAM 编码(Base64)的后缀是： .PEM .CER .CRT
.cer/.crt是用于存放证书，它是2进制形式存放的，不含私钥。
.pem跟crt/cer的区别是它以Ascii来表示。
pfx/p12用于存放个人证书/私钥，他通常包含保护密码，2进制方式
p10是证书请求
p7r是CA对证书请求的回复，只用于导入
p7b以树状展示证书链(certificate chain)，同时也支持单个证书，不含私钥。

一 用openssl创建CA证书的RSA密钥(PEM格式)：
openssl genrsa -des3 -out ca.key 1024

二用openssl创建CA证书(PEM格式,假如有效期为一年)：
openssl req -new -x509 -days 365 -key ca.key -out ca.crt -config openssl.cnf
openssl是可以生成DER格式的CA证书的，最好用IE将PEM格式的CA证书转换成DER格式的CA证书。

三 x509到pfx
pkcs12 -export –in keys/client1.crt -inkey keys/client1.key -out keys/client1.pfx

四 PEM格式的ca.key转换为Microsoft可以识别的pvk格式。
  pvk -in ca.key -out ca.pvk -nocrypt -topvk
五 PKCS#12 到 PEM 的转换
openssl pkcs12 -nocerts -nodes -in cert.p12 -out private.pem
验证 openssl pkcs12 -clcerts -nokeys -in cert.p12 -out cert.pem
六 从 PFX 格式文件中提取私钥格式文件 (.key)
openssl pkcs12 -in mycert.pfx -nocerts -nodes -out mycert.key
七 转换 pem 到到 spc
openssl crl2pkcs7 -nocrl -certfile venus.pem  -outform DER -out venus.spc
用 -outform -inform 指定 DER 还是 PAM 格式。例如：
openssl x509 -in Cert.pem -inform PEM -out cert.der -outform DER
八 PEM 到 PKCS#12 的转换，
openssl pkcs12 -export -in Cert.pem -out Cert.p12 -inkey key.pem

密钥库文件格式【Keystore】

 格式     :  JKS
 扩展名  : .jks/.ks
 描述     : 【Java Keystore】密钥库的Java实现版本，provider为SUN
 特点     :  密钥库和私钥用不同的密码进行保护
 
 格式     :  JCEKS
 扩展名  :  .jce
 描述     : 【JCE Keystore】密钥库的JCE实现版本，provider为SUN JCE
 特点     :  相对于JKS安全级别更高，保护Keystore私钥时采用TripleDES
 
 格式     :  PKCS12
 扩展名  :  .p12/.pfx
 描述     : 【PKCS #12】个人信息交换语法标准
 特点     :  1、包含私钥、公钥及其证书
               2、密钥库和私钥用相同密码进行保护
 
 格式     :  BKS
 扩展名  : .bks
 描述     :  Bouncycastle Keystore】密钥库的BC实现版本，provider为BC
 特点     :  基于JCE实现
 
 格式     : UBER
 扩展名  : .ubr
 描述     : 【Bouncycastle UBER Keystore】密钥库的BC更安全实现版本，provider为BC

证书文件格式【Certificate】
格式          :  DER
扩展名       :  .cer/.crt/.rsa

描述          : 【ASN .1 DER】用于存放证书
特点          :  不含私钥、二进制

格式          :  PKCS7
扩展名       : .p7b/.p7r
描述          : 【PKCS #7】加密信息语法标准

特点          : 1、p7b以树状展示证书链，不含私钥
                  2、p7r为CA对证书请求签名的回复，只能用于导入

格式          :  CMS
扩展名       :  .p7c/.p7m/.p7s
描述          : 【Cryptographic Message Syntax】
特点          : 1、p7c只保存证书
                  2、p7m：signature with enveloped data
                  3、p7s：时间戳签名文件
 
格式          :  PEM
扩展名       : .pem
描述          : 【Printable Encoded Message】
特点          : 1、该编码格式在RFC1421中定义，其实PEM是【Privacy-Enhanced Mail】的简写，但他也同样广泛运用于密钥管理
                  2、ASCII文件
                  3、一般基于base 64编码

格式         :  PKCS10
扩展名      : .p10/.csr
描述         : 【PKCS #10】公钥加密标准【Certificate Signing Request】
特点         :  1、证书签名请求文件
                  2、ASCII文件
                  3、CA签名后以p7r文件回复

格式         :  SPC
扩展名      : .pvk/.spc
描述         : 【Software Publishing Certificate】
特点         :  微软公司特有的双证书文件格式，经常用于代码签名，其中
                  1、pvk用于保存私钥
                  2、spc用于保存公钥

转自http://blog.csdn.net/hansel/article/details/4447631

X509和PKCS的关系讨论：http://topic.csdn.net/u/20071015/18/37a2bffb-2354-493e-b5a9-b96ab28063ae.html

http://www.carillon.ca/library/pkitutorial.php

In recent years, two of the main hurdles encountered when using data networks for collaborative work and the transmission of sensitive information have been, in no particular order:

• data confidentiality, or ensuring that the information can only be read by the people who are supposed to read it; and
• data integrity, or ensuring that the information received is exactly the information that was sent.

Basic encryption

Various techniques have been available to solve those issues, usually through the use of cryptographical tools. The basic approach is to use a specific mathematical formula (the cipher) into which a series of numbers (the secret key) can be plugged; when this formula is applied to some data (called the plaintext), this data is turned into an unintelligible mass of characters (called the ciphertext).

The transformation of plaintext into ciphertext is called encryption; the reverse process is called decryption.

Only someone who knows what cipher and what secret key were used can return the ciphertext back to the original plaintext. Usually, the cipher is well-known, but the secret key is, well, secret.

The cipher must guarantee two things:

• without the secret key, absolutely no part of the plaintext can be reconstructed from the cyphertext; and
• with the secret key, the entire plaintext can be unambiguously reconstructed from the cyphertext.

Let's put this in an example. May we introduce Alice and Bob, who are trying to exchange information. But in the shadows lurks Eve, the Eve-ildoer who is trying to Eve-sdrop on the information being exchanged between Alice and Bob.

Alice and Bob, who know each other and plan on exchanging data in a secure fashion, meet face-to-face and choose a secret key. At a later time, when Alice wants to send Bob some confidential data, she takes that plaintext and applies the cipher to it, using the pre-arranged secret key. The resulting ciphertext is sent via the network to Bob, including some information, such as which cipher was used. Bob receives the ciphertext, applies the reverse cipher with the secret key, and obtains the original plaintext.

Our eavesdropping Eve also manages to get a copy of the ciphertext; however, she can't make sense of its contents. Even knowing which cipher was used, without the secret key, she can't decrypt the captured data back to its original plaintext form.

This takes care of data confidentiality; if Alice wants only specific people to access a certain piece of encrypted information, she can give the secret key to only those people. But how does it address data integrity? It doesn't, at least not directly. If something interferes with the ciphertext during transit, decrypting it will generate unintelligible data. However, as far as Bob is concerned, the original plaintext might not have been intelligible data in the first place, so he has no proof that the data was or wasn't altered.

Another technique, data hashing, will help Alice with that objective.

Data hashing

To guarantee data integrity, a new mathematical tool is needed. A hash function is another (and very different) mathematical formula through which our plaintext will be processed, producing a fixed-length result called a hash sum. This hash function presents the following characteristics:

• a specific plaintext produces a specific hash sum;
• the hash sum cannot be used to reconstruct any part of the plaintext; and
• it is impossible to craft a different plaintext that produces the same hash sum.

How is that useful? Imagine Alice produces a hash sum for a specific plaintext and then encrypts the hash sum with the secret key she shares with Bob. If she joins that encrypted hash sum with her original message, Bob can decrypt the hash sum sent by Alice and then calculate his own hash sum from the plaintext. If both hash sums match, it means the retrieved plaintext is indeed identical to what Alice sent. If the hash sums differ, the message was modified at some point.

If Eve intercepts the message and tries to modify it, she can't create a new encrypted hash sum that will correspond to the modified message, since she doesn't have the secret key. Therefore, data integrity can be achieved.

So, it would seem that encryption and data hashing solve our confidentiality and integrity issues. There is, however, a major problem with this approach. Our initial premise is that Alice and Bob meet before any data exchange to establish a secret key. What if Alice and Bob are halfway around the world? That complicates the meeting. What if Alice wants to communicate securely with Bob, but also with Charlie, Dennis and Fred? That forces her to hold additional meetings. And if Bob also wants to communicate with Charlie, Dennis and Fred? Even more meetings. And what if they all need to communicate now, without having met before?

Enter public-key cryptography.

Public-key cryptography

A more complex but extremely useful approach is asymmetric cryptography, also known as public-key cryptography (yes, this is the same "Public Key" as in "Public Key Infrastructure"!), which will now be the focus of our interest.

Public-key cryptography revolves around the use of a mathematically linked pair of keys, one designated public and the other designated private. This mathematical linkage is such that plaintext encrypted using one of the keys can only be decrypted using the other key. A specific individual has her own pair of keys, keeping the private key absolutely private and the public key as public as possible.

How does this apply to our quandary? If Alice has in hand her own public key (Pub_A), her own private key (Priv_A), and Bob's public key (Pub_B), she can do the following:

• encrypt the plaintext with Bob's public key (Pub_B);
• calculate the hash sum of the plaintext and encrypt it with her own private key (Priv_A); and
• combine the ciphertext and the encrypted hash sum in a message and send it to Bob.

Upon receiving this message, Bob, who should have in his posession his own public key (Pub_B), his own private key (Priv_B), and Alice's public key (Pub_A), can do the following:

• decrypt the ciphertext with his own private key (Priv_B);
• decrypt the hash sum with Alice's public key (Pub_A);
• calculate the hash sum of the plaintext and compare it with the decrypted hash sum.

Bob therefore obtains the plaintext and, if the hash sums are the same, the guarantee that it hasn't been altered in transit.

What if Eve intercepts the message sent by Alice? Eve has her own public key (Pub_E), her own private key (Priv_E), Alice's public key (Pub_A) and Bob's public key (Pub_B). Unfortunately for her, this doesn't do her any good; since she doesn't have Bob's private key, she can't retrieve the plaintext, and since she doesn't have Alice's private key, she can't modify the message and encrypt a new hash sum.

Data confidentiality and integrity are therefore assured, without forcing everybody to meet beforehand. All that's needed is a way to distribute public keys.

Digital signature

Before we tackle the issue of distribution, there's an interesting concept that deserves a little detour. When Alice applies a hash function to a plaintext and encrypts the obtained hash sum with her private key, the result is called a digital signature.

A digital signature guarantees two things:

• if the decrypted hash sum matches the hash sum of the plaintext, the plaintext received corresponds to the plaintext sent by Alice
• if the hash sum can be decrypted with Alice's public key, it proves the document was indeed sent by Alice (actually, it only proves the document was sent by someone who has Alice's private key, which we take for granted is Alice - we'll come back on this matter a bit later).

The latter is an important point - the digital signature proves the document was indeed sent by Alice, and Alice cannot claim she didn't send it.

Of course, this all takes for granted that Alice is the only one who can access her private key. If a private key is compromised, i.e. if it falls into someone else's hands, the associated public key becomes useless. Worse, it becomes dangerous, because people might still think it valid and believe that something signed with Alice's private key indeed comes from Alice. In the other direction, plaintext encrypted with Alice's public key will actually be readable by everyone who has access to Alice's private key. The simple moral of this is - private keys are an extremely sensitive piece of information, and must be kept utterly safe, at all times.

Certificates

There is one major problem left. For the system to work, Alice must be absolutely sure that the public key with which she encrypts the plaintext is indeed Bob's. Should she be tricked in using Eve's, for example, Eve would then be able to decrypt the ciphertext and access the plaintext.

Or, if what Bob thinks is Alice's public key is actually Eve's, Eve can sign a document that Bob will believe is coming from Alice.

Therefore, while the public keys per se are not meant to be secret, it is imperative that the person the public key is associated with be ascertained. This could be done through a face-to-face meeting, as we initially did at the beginning of this conversation; however, this is no more practical now than it was back then.

Back to the drawing board? Not quite. There might be an acceptable compromise.

What if Alice and Bob have a common friend, named Charlie. Charlie travels a lot, meets a lot of people, and is an all-around pleasant and very, very reliable individual. If, during his travels, Charlie has met with Alice and exchanged public keys with her, he now has a copy of Alice's public key that he is sure belongs to Alice, and Alice has a copy of Charlie's public key that she is sure belongs to Charlie. The next time Charlie meets with Bob, they can not only exchange public keys, but if Bob really trusts Charlie, he can also accept his copy of Alice's public key with assurance that it is indeed Alice's.

Charlie can even take this one step further; he can take Bob's public key, digitally sign it with his own private key, and send this to Alice. Alice is sure of her copy of Charlie's public key, so she can trust that this indeed comes from Charlie. And if she trusts Charlie to be a thorough and reliable individual, she can also accept what she has just received as Bob's public key.

If Charlie also meets Dennis and Fred, this process can be expanded even further. All the people who trust Charlie to do a good job can now have reliable access to each other's public key, just by meeting Charlie once.

There's a specific name for a public key digitally signed by someone many people trust; it is called a certificate. Usually, there is also some additional information enclosed, such as the name, organisation, email address, etc. of the person whose public key is contained within the certificate.

And now to the core of the matter...

Public Key Infrastructure

So what is a Public Key Infrastructure or PKI? It is a system designed to allow the creation and distribution of those certificates. In technical terms, it is the combination of:

• a Registration Authority (or RA), in charge of verifying people's identity and associating that identity with their public key
• a Certification Authority (or CA), in charge of generating certificates, i.e. signing people's public key and identity information with its own private key
• a validation system that can confirm whether a specific certificate produced by this CA is still valid or not (for example, because the associated private key was lost or compromised, or because some information contained within has changed)

In other words, it's a Charlie. It's someone who participants can have direct contact with, who can validate people's identity and accept their public key, who can generate certificates for them and who can distribute those certificates. It's someone who is extremely meticulous and absolutely trustworthy, and who people trust.

What makes it even more useful is that PKIs can trust each other, under very specific conditions; when this occurs, a PKI's participants (or subscribers, as they are officially called) can access and trust the certificates of the other PKI's subscribers.

While it may not seem that way, the technical side of a PKI is fairly simple. What is complex is that to be of any use, it must be trusted by its subscribers, and must be deserving of that trust. This comes through the creation of very specific and very strict sets of rules and guidelines, that must be transparent, auditable and followed at all times. Those rules are enumerated in a document called the Certificate Policy (or CP), which states how the PKI must function.

So in a nutshell, a PKI is a system that guarantees that a specific public key belongs to a specific identity. What can be done with it? A lot.

For a more detailed yet still very reader-friendly look at PKI and its underlying concepts, we encourage you to take a look at our world-renowned PKI Fingerpuppet Theatre.