Java开发网 - Re:[转载]论Java加密技术与Windows的结合（2）

Java开发网

您没有登录

» Java开发网 » Java Security

打印话题 寄给朋友 订阅主题

作者

[转载]论Java加密技术与Windows的结合（2）

samuel

发贴: 50
积分: 10

于 2003-08-22 11:19

公共钥匙加密算法

　　公共钥匙加密有两个目的：加密和数字签名。公共钥匙加密运用一个包含两部分的钥匙（或一对钥匙）：一个私钥和一个公钥。公钥带有开始和终止日期、一个序号、一个身份（称为Subject Distinguished Name）、和一个CA的签名（见列表1）。RSA是最常用的公共钥匙加密算法。

公共钥匙加密运用一个公钥和一个私钥。一个数字证书（如下所示）包含公钥、开始和结束日期、一个序号、一个身份和一个证书授权中心（CA）的签名。
Serial number:
6822 3C33 7945 3AC8 F8C5 398B 7469 94E1
Signature algorithm: md5RSA
Issuer: CN = VeriSign Class 1 CA Individual
Subscriber-Persona Not Validated,
OU = www.verisign.com/repository/RPA Incorp.
By Ref.,LIAB.LTD（c）98,
OU = VeriSign Trust Network, O = VeriSign, Inc.
Valid from: Wednesday, May 30, 2001 7:00:00 PM
Valid to: Monday, July 30, 2001 6:59:59 PM
Subject: E = boyter@txdirect.net,
CN = Brian Boyter,
OU = Digital ID Class 1 <\? Microsoft,
OU = Persona Not Validated,
OU = www.verisign.com/repository/RPA Incorp.
by ref.,LIAB.LTD（c）98,
OU = VeriSign Trust Network, O = VeriSign, Inc.
Public key: 3081 8902 8181 00BA B459 0F39 156E
C69E C238 BFD0 401D DBB9 D207 DFA4 5DBD 09F3
5CE6 B5E6 C357 8 Cool

D 808B 0699 5F68 A2A4 6A8A
3B21 6D3D D0A1 1E5F DAB1 FB8E F835 F84F 849B
29A4 6943 Cool

59 0669 7C81 1D00 03B7 1A02 4E7A
8596 11BD 7CC4 07A3 D7E5 9FF6 5684 B853 04F0
0938 A11E 5218 F9AB F034 070D C8C4 6652 C19B
4C57 E435 EFDC 85D4 B269 07B7 0102 0301 0001
Basic constraints: Subject Type=End Entity,
Path Length Constraint=None
Certificate policy:
Policy Qualifier Id=CPS Qualifier:
https://www.verisign.com/CPS
Policy Qualifier Info:
Organization=VeriSign, Inc.,
Notice Number=1
CRL Distribution Point Distribution Point Name:
Full Name:
URL=http://crl.verisign.com/class1.crl
Thumbprint algorithm: sha1
Thumbprint: 74A8 9F07 43AA 8FFC C4D5 AB09 3773 3AFF F7E7 DFFC

　　公共钥匙加密中的加密是用公钥来完成的，解密是用私钥完成的。公共钥匙加密对于大量的加密来说运算很复杂，但它却被广泛用来分配密钥。密钥，或对称加密算法，如DES和RC4，通常用于大量的加密，但是密钥加密算法需要一些保密的方法来交换用于大量加密的钥匙。一种技术是生成一个随机数，用公共钥匙加密算法来加密那个随机数，然后将加密了的随机数发送给远端的同伴。发送者用远端同伴的公钥来加密随机数。接收者用它自己的私钥来解密这个随机数。任何截取了加密的随机数的第三方都不能解密那个随机数，因为他没有私钥。

　　在数字签名中，用私钥来完成签名，用公钥来完成确认。被签名了的文件通常是经过哈希算法处理过的。哈希算法是一个单向算法，它可以减小文件的大小。运用MD5哈希算法，文件被简小到16字节。运用SHA1哈希算法，文件被简小到20字节。然后，就用签名人的私钥对经哈希算法处理过的文件进行加密。任何人都可以用签名人的公钥来解密哈希文件。

　　你必须非常小心地保护私钥。Windows将私钥以有些令人迷惑的形式存储在文件系统中。一个恶意的侵犯者可以进入到你的计算机并找到你的私钥。任何得到了你的私钥的人都可以化装成你，在你不知道的情况下做出签署文件等行为。一种保护私钥的方法就是用一个加密的智能卡，该卡上存储了私钥。运用一个加密的智能卡，用户仍然可以进行公钥加密和签名活动，但没有人——甚至用户——可以读取私钥。智能卡有一个RSA加密和签名处理器，只有这个RSA处理器有权使用私钥。

　　当一个SSL服务器向一个SSL客户端确认身份时，客户端必须根据下面这些标准来确定服务器的证书是否有效：
　　· 证书必须有一个信任链，其根CA必须是客户端信任的。
　　· 服务器证书，和信任链中所有的CA证书必须有有效的签名。每个证书都是由下面更高级的CA来签署的，除了根CA外，它签名自己的证书。
　　· 当前的日期和时间必须在服务器证书的有效期内，而且也在信任链中所有证书的有效期内。每个证书都有一个有效期（证书可以有效使用的一个开始日期和时间以及结束日期和时间）。
　　· 每个CA应该管理和公布一个CRL。客户端必须可以从信任链中的每个CA得到CRLs，来查看服务器证书或下属CA的一个证书是否已被其下面更高级的CA撤消了。
　　· 证书必须可以有效用于其目的。钥匙的用途定义在证书中。例如，CA批准的仅用于数字签名的一个钥匙就不能用于SSL钥匙交换。

　　Java安全实现环境中不进行证书撤消确认，就是说，它不进行CRL处理。我将向你展示如何运用Microsoft Windows的本地加密函数来检查证书信任链中的CRLs，从而为Java实现一个TrustManager和KeyManager。

　　TrustManager

　　javax.net.ssl.X509TrustManager有三个方法，你可以在MSTrustManagerlmpl.java中找到： · getAcceptedIssuers（）为Microsoft证书库中的所有CAs返回一组证书。
　　· checkClientTrusted（）执行服务器的安全策略。
　　· checkServerTrusted（）执行客户端的安全策略。

　　一个典型的TCP网络安全策略是：

　　· 客户端开始连接。假设客户端只连接到“安全的”服务器。客户端应该要求服务器用一个数字证书向客户端证明身份。通过确认服务器的证书（信任链、签名是有效的，有效期、证书没有被撤消，而且证书是批准用于RSA钥匙交换的），客户端确认服务器的真实性。客户端通过有效的证书来信任服务器。
　　· 服务器接收来自所有客户端的TCP连接，有些客户端可能是恶意的。服务器可以要求客户端用一个数字证书向服务器证明身份。那样的话，客户端的身份就可以被确认，而且多种信任级别也可以实现了。如果服务器不要求客户端证明身份，服务器应该假设所有的客户端都是恶意的。

　　你可以在checkServerTrusted（）中看到，实现客户端安全策略是很容易的。CheckServerTrusted（）检查签名、信任链中证书的有效日期和CRLs。（我在后面会探讨证书撤消处理。）checkClientTrusted（）方法与checkServerTrusted（）是一样的。一般来说，这个安全策略对服务器来说并不够。一种增强服务器安全状态的方法就是要求客户端用数字证书来证明身份，只接受由一个特定的CA（如VeriSign CA）发布的证书，并且检验证书的Subject Distinguished Name中的特殊字段（如0=sun.com）。只需要几行Java代码就可以把这个过程添加到checkClientTrusted（）中了。你需要定制checkClientTrusted（）来实现你的安全策略（见列表2）。

checkClientTrusted（）方法检查签名、信任链中证书的有效日期和CRLs。但是，对服务器来说，这个安全函数并不够。你可以通过定制checkClientTrusted（）来增强安全策略。
public void checkClientTrusted（
X509Certificate chain[]） {
// DontKnowFlag indicates what to do if we're
// not sure if the certificate is revoked
// int DontKnowFlag=0； // reject the cert
// int DontKnowFlag=1； // accept the cert
int DontKnowFlag=2； // ask the user
// check for revoked certs in the cert chain
if （com.boyter.mscrypto.MSValidCertificate.
isCertChainValid（chain, DontKnowFlag））
return；

// client cert is not trusted
System.out.println（"Client Certificate is not Trusted - aborting"）；
System.exit（2）；
}

　　Java提供了几个与证书链处理相关的类，在Java Certification Path API Programmer's Guide中有进一步说明。我对它们做过实验，最后决定不用它们，因为我认为它们太复杂了。

　　TrustManager有第三个方法getAcceptedIssuers（）。该方法为Microsoft证书库中所有CAs返回一组证书。Microsoft将这些证书存储在Registry中；你可以通过启动REGEDIT程序并查看HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates找到它们。GetAcceptedIssuers（）方法执行了Microsoft的本地函数CertEnumCertificateslnStore（）。CA证书被作为一组base64位编码的字符串传回到Java方法。Java.security.cert.CertificateFactory将base64编码的证书转换成Java证书。

作者

Re:[转载]论Java加密技术与Windows的结合（2） [Re:samuel]

samuel

发贴: 50
积分: 10

于 2003-08-22 11:24

证书撤消

　　有两种撤消证书的方法：Online Certificate Status Protocol（OCSP）和CRL。OCSP（见RFC2560）并没有得到广泛的支持，所以我只探讨用来确认一个证书的撤消状况的CRLs。CAs定期公布一个CRL（见RFC2459）。CRL是一列证书序号，由CA签署。如果一个证书的序号列在CRL中，那个证书就被撤消了，不再有效了。大多数证书在发布时，都有一个称为CRL Distribution Point（CDP）的扩展名。CDP通常是一个HTTP或Lightweight Directory Access Protocol（LDAP）URL，它指明该CRL存储在哪里。我的VeriSign证书的CDP是http://crl.verisign.com/class1.crl。该CRL有500多K，所以需要花些时间来下载。

　　Java的确提供了类java.security.cert.LDAPCertStoreParameters，它可以用来从一个LDAP目录获取一个CRL，但这并不适用于VeriSign CRL（因为那个CRL存在一个Web服务器上，而不是一个LDAP服务器上）。Microsoft有一个比Java更丰富的API用来管理证书撤消。如果你浏览一个安全的网站（HTTPS），IE将会检验服务器的证书是否已被撤消（假设服务器的证书有一个CDP）。IE将从证书链中的CAs获取CRLs并把它们缓存到IE的Temporary Internet Files（临时Internet文件）目录中。在下一次需要来自那个CA的CRL时，IE将首先检查缓存。如果它在缓存中找到该CRL，IE会检查该CRL是否过期。（CRLs也有有效的from/to期限。VeriSign运用一个10天的有效期限。）如果CRL已经过期，IE将获取一个新的CRL。

　　我考虑开发一个只用于Java的CRL获取、缓存和撤消确认过程——但是那样会需要大量的Java代码，需要支持几个URL协议（HTTP、LDAP、FTP、文件），需要用一个文件来存储CRL缓存，而且需要复制Microsoft提供的底层框架。目的是运用IE的证书撤消底层框架。

　　Microsoft提供了一个函数CertVerifyRevocation（），它与IE缓存结合起来了并按需要下载和处理CRLs。我琢磨了好几周撤消过程，最后得到了一个可靠的算法。当CertVerifyRecocation（）下载一个CRL时，下载有时会中断。这就使CertVerifyRevocation（）返回假的、很难恢复的错误状况。我实现的过程显示在图1中。

图1. 证书撤消流程表

　　其诀窍就是调用函数CryptRetrieveObjectByUrl（）来从LDAP、HTTP或FTP服务器预取CRL到IE缓存中，然后调用CertVerifyRevocation（）来检查这个证书是否已被撤消。虽然CryptRetrieveObjectByUrl（）下载仍然要受到网络的影响，造成连接中断，但运用CryptRetrieveObjectByUrl（）的好处就是你可以识别问题，报告一个有意义的错误信息，并且（如果你需要）可以提示用户接受或拒绝该证书。不幸的是，只有Windows 2000或更高版本中有CryptRetrieveObjectByUrl（）。如果程序要在Windows 98或Windows NT4上运行，你就不能预取CRL。

　　我也尝试运用Microsoft函数来下载CRLs，然后在Java中处理CRL。对于一个大的CRL（比如VeriSign CRL），这种方式很慢。

　　列表3显示关于isCertRevoked（）方法的Java代码片段。IsCertRevoked（）方法调用了两个本地函数，MSgetCRL（）和MSVerifyCertRevocation（）。MSgetCRL（）调用Microsoft函数CryptRetrieveObjectByURL（），如果CRL不在缓存中，它可以使CRL被下载。你不需要把CRL传递到Java中，因为它从来不用在Java中。函数MSCertVerifyRevocation（）调用Microsoft函数CertVerifyRevocatoin（）来确定一个证书是否被撤消了。列表4显示关于MSgetCRL（）和MSVerifyCertRevocation（）的代码片段。警告：当我第一次在Windows 2000 Server PC上测试CertVerifyRevocation（）时，它没有运行。在我将PC升级到Service Pack 2后，重新测试就很成功。

我们的确认程序中的isCertRevoked（）方法调用了两个本地函数：MSgetCRL（）和MSVerifyCertRevocation（）（如列表4所示）。
boolean isCertRevoked（X509Certificate cert,
int DontKnowFlag） {
byte[] certblob = cert.getEncoded（）；
// Does the cert have a CDP （
// CRL distribution point）???
byte[] CDPblob = cert.getExtensionValue（
"2.5.29.31"）；

// yes there is a CDP - ASN parse the CDP
String[] URLarray = MSF.MSparseCDP（CDPblob）；
for （int i=0； i＜URLARRAY.LENGTH； i++） String URL = URLarray[i]；
// go fetch that CRL
if （MSF.MSgetCRL（URL）） {
// url was fetched correctly
break；
}

// is the cert revoked???
int revocationStatus =
MSF.MSVerifyCertRevocation（certblob）；
switch （revocationStatus） {
case 0: // cert is revoked
return AskUserWhatHeWantsToDo（DontKnowFlag）；
case 1: // cert is not revoked
return false；
default:
}

// processing error - cannot determine
// if cert is revoked
return AskUserWhatHeWantsToDo（DontKnowFlag）；
}

函数MSgetCRL（）和MSVerifyCertRevocation（）由方法isCertRevoked（）调用（如列表3所示）。MSgetCRL（）调用Microsoft函数CryptRetrieveObjectByURL（），如果在缓存中没有CRL，可以用该函数来下载它。函数MSVerifyCertRevocation（）调用Microsoft函数CertVerifyRevocation（）来查看一个证书是否已被撤消。
MSgetCRL（jstring jurl）
{
if （!CryptRetrieveObjectByUrl（
url, CONTEXT_OID_CRL, 0, timeout*1000,
（LPVOID）&crl, NULL, NULL, NULL, NULL）） {
printf（"CryptRetrieveObjectByUrl failed\n"）；
// cached url is corrupted
DeleteUrlCacheEntry（url）；
return JNI_FALSE；
}
return JNI_TRUE；
}

MSVerifyCertRevocation （jbyteArray jCert）
{
rgpvContext[0] = （PVOID）pCertContext；
if （CertVerifyRevocation（X509_ASN_ENCODING,
CERT_CONTEXT_REVOCATION_TYPE, 1, rgpvContext,
0, NULL, &status）） {
return 1； // cert is not revoked
}

if （status.dwError == CRYPT_E_REVOKED）
return 0； // cert is revoked

return -2； // processing error
}

samuel edited on 2003-08-22 11:29

作者

Re:[转载]论Java加密技术与Windows的结合（2） [Re:samuel]

samuel

发贴: 50
积分: 10

于 2003-08-22 11:30

KeyManager

　　javax.net.ssl.X509KeyManager有六个方法：
　　· getClientAliases（）返回一组客户端别名。（这里的一个别名就是带有一个RSA私钥和证书的一个身份。）
　　· getServerAliases（）返回一组服务器别名。
　　· chooseClientAlias（）从一组别名中选择一个客户端别名。
　　· chooseServerAlias（）从一组别名中选择一个服务器别名。
　　· getCertificateChain（）为一个证书返回有序的证书链。
　　· getPrivateKey（）为一个别名返回私钥。

　　Microsoft将私钥和它们相关的证书存储在文件系统中。我的私钥和证书存储在目录C:\Documents和Settings\Administrator\Application Data\Microsoft中。你不需要知道钥匙存储在哪里，因为Microsoft提供了一个API用来访问钥匙和证书库。

　　KeyManager的getClientAliases（）和getServerAliases（）方法执行Microsoft本地的函数CertEnumCertificateslnStore（），查看Microsoft的“My”证书库中的所有证书。“My”证书库中的证书应该有一个与它们相关连的私钥。每个证书/私钥组合都有一个特殊的标识符，称为CONTAINER；这就相当于Java中的“别名”（见列表5）。

CertEnumCertificatesInStore（）方法查看Microsoft中“My”证书库中所有的证书；每个证书都有一个相关的私钥。每个证书/私钥组合都有一个标识符，称为CONTAINER，这就相当于Java中的别名。
JobjectArray MSgetAliases （jstring jcertStore） {
// open Microsoft certificate store
hSystemStore = CertOpenStore（
CERT_STORE_PROV_SYSTEM,
0, 0, CERT_SYSTEM_STORE_CURRENT_USER,
certStore）；

// read all the certificates
while（pCertContext=
CertEnumCertificatesInStore（
hSystemStore, pCertContext）） {

// get the cert key container name
CertGetCertificateContextProperty（
pCertContext, CERT_KEY_PROV_INFO_PROP_ID,
alias, &propLen）；

// add to list of aliases
AddDataToList（&list, alias, strlen（alias）+1）；
}
return jaliases；
}

列表5

　　方法chooseClientAlias（）和chooseServerAlias（）从一列别名中返回一个客户端（或服务器）别名。如果只有一个别名，在选择别名时就不会有歧义。因为Java的创始人对于选择运用哪个别名并没有提供任何特殊的指导，我就选择了清单中第一个别名。另一个选择合适的客户端别名的方法就是提示用户从一列可能的别名中选择一个别名。（在SSL客户端，你通常可以这么做，但在服务器上不行。）

　　KeyManager的getCertificateChain（）方法为一个证书返回有序的证书链。该方法通过调用getAcceptedIssuers（）方法得到一列可信任的证书签发者。首先我们找到证书签发者的Distinguished Name（DN），然后我们查看是否有哪个可信任的签发者有那个DN。几个签发者可以有同一个DN。对于具有签发者DN的每个证书，我们提取公钥并尝试在原始证书上确认签名。如果没有一个签发者有正确的DN和正确的公钥，证书链就被破坏了，出现一个异常。如果我们找到了正确的签发者签发的证书，我们就重复上述过程来查找和确认那个证书的签发者。重复该过程，直到我们达到根CA。对于一个根CA，Subject DN和签发者DN是一样的（见列表6）。

方法getCertChain（）为一个证书返回有序的证书链。
MSCryptoFunctions MSF = new MSCryptoFunctions（）；
X509Certificate[] getCertChain（
X509Certificate cert） {
try {
getCACerts（）；

Principal subject = cert.getSubjectDN（）；
Principal issuer = cert.getIssuerDN（）；
CertChainList.add（cert）；

// stop if issuer==subject （root CA）
while （!（issuer.equals（subject））） {

match = false；
X509CertSelector xcs =
new X509CertSelector（）；
xcs.setCertificateValid（new Date（））；

Collection certcollection =
CACerts.getCertificates（xcs）；

//
// the next 7 lines are inserted to work
// around a problem with X509CertSelector.
// we should be able to do this with
// xcs.setSubject（issuer.toString（））；
//
Iterator iter = certcollection.iterator（）；
while （ iter.hasNext（）） {
X509Certificate cacert =
（X509Certificate）（iter.next（））；
if （!cacert.getSubjectDN（）.equals（issuer））
iter.remove（）；
}

issuerArray =
new X509Certificate[
certcollection.size（）]；
issuerArray = （X509Certificate[]）
certcollection.toArray（issuerArray）；

for （int i=0； i<\<>issuerArray.length； i++）
if （verifySignature（issuerArray[i], cert））{
match = true；
cert = issuerArray[i]；
subject = cert.getSubjectDN（）；
issuer = cert.getIssuerDN（）；
CertChainList.add（cert）；
break；
}
if （!match） {
return null； // cert chain broken
}
}
} catch （Exception e） {
e.printStackTrace（）；
}

X509Certificate[] CertChain =
new X509Certificate[CertChainList.size（）]；
CertChainList.toArray（CertChain）；

return CertChain；
}

　　getPrivateKey（）方法为一个别名返回私钥，假设私钥可以从Microsoft钥匙库中输出。记住，有时私钥是不能输出的。（例如，如果你用了一个加密了的智能卡，那么就没人可以从智能卡上读取私钥了。）如果不能输出私钥，getPrivateKey（）就返回一个虚拟的私钥。所以，如果getPrivateKey（）不能得到私钥，我们就骗Java，让它认为得到了私钥。getPrivateKey（）也缓存别名，所以，当一个Java程序试图执行一个RSA数字签名函数时，我们就会知道运用哪个私钥了（缓存的别名），而且Microsoft加密提供者就可以执行我们想要的RSA签名或解密函数了（见列表7）。

方法getPrivateKey（）为一个别名返回私钥，假设私钥可以从Windows钥匙库中输出。
MSCryptoFunctions MSF = new MSCryptoFunctions（）；
public PrivateKey getPrivateKey（String alias） {
// get the private key from MS Windows for
// this alias
byte[] keyblob = MSF.MSgetPrivateKey（alias）；

if （keyblob == null） { // generate a dummy key
byte[] modblob = new byte[128]；
for（i=0； i<128； i++）
modblob[i] = 127；
mod = new BigInteger（modblob）；
exp = mod；

} else { // use the key that got exported
for（i=0； i
modblob[i] = keyblob[19-i+（keysize/16）*2]；
expblob[i] = keyblob[19-i+（keysize/16）*9]；
}
mod = new BigInteger（1, modblob）；
exp = new BigInteger（1, expblob）；
}
RSAPrivateKeySpec privKeySpec =
new RSAPrivateKeySpec（mod, exp）；
KeyFactory kf = KeyFactory.getInstance（"RSA"）；
privkey = kf.generatePrivate（privKeySpec）；
return privkey；
}

作者

Re:[转载]论Java加密技术与Windows的结合（2） [Re:samuel]

samuel

发贴: 50
积分: 10

于 2003-08-22 11:33

RSA Signature Provider

　　java.security.SignatureSpi类有五个方法：
　　· engineInitSign（）为签名初试化RSA签名引擎。
　　· engineInitVerify（）为确认一个签名初试化RSA签名引擎。
　　· engineUpdate（）增加数据到签名或确认操作。
　　· engineSign（）完成签名操作并返回数字签名。
　　· engineVerify（）完成签名-确认过程，如果签名是正确的，返回true。

　　记住，数字签名需要私钥，确认一个数字签名需要公钥。如果我们有权使用Microsoft的私钥——即，私钥是可输出的——就没必要在Microsoft本地代码中执行RSA签名操作了。但是在有些情况下（例如，如果我们运用一个加密了的智能卡），我们无权使用私钥。如果私钥是不能输出的，我们必须用Microsoft本地代码进行数字签名。

　　如果Java程序运用KeyManager的方法getPrivateKey（）来获取私钥，私钥的别名就被缓存起来。当RSA Signature Provider进行签名时，我们就重用缓存的别名，并调用Microsoft本地函数来执行签名操作而不用暴露私钥。（这听起来有些虚假，但确实可行。）注意，在engineInitSign（）中没有用私钥。我用Java JCE哈希函数来进行运算，然后用Microsoft Cryptographic Provider从哈希文件中生成RSA签名。

　　通过添加一个engineInitSign（字符串别名）方法，可以改进Java Signature类：

MSCryptoFunctions MSF =
new MSCryptoFunctions（）；
protected void engineInitSign（
PrivateKey privateKey） {
MSF.MSrsaSignInit（（byte[]）null,
"MD5"）；
}

protected byte[] engineSign（） {
byte[] hash = MD5.digest（）；
byte[] mssig =
MSF.MSrsaSignHash（hash,
（byte[]）null, "MD5"）；
return mssig；
}

　　我们可以在Microsoft本地代码中实现签名-确认，但这么做没有优势。在实现过程中，我们运用了JSSE提供者在Java中执行确认：

protected void engineInitVerify（
PublicKey publicKey） {
jsse = Signature.getInstance（
"MD5withRSA", "SunJSSE"）；
jsse.initVerify（publicKey）；
}

protected boolean engineVerify（
byte[] sigBytes） {
boolean verifyresult=false；
verifyresult =
jsse.verify（sigBytes）；
return verifyresult；
}

　　RSA Cipher Provider

　　javax.Crypto.CipherSpi类有12个方法：
　　· engineInit（）初试化密码提供者（cipher provider）。
　　· engineUpdate（）继续一个由多个部分组成的加密或解密操作。
　　· engineDoFinal（）加密或解密一个单一操作中的数据，或完成一个由多个部分组成的操作。
　　· engineGetBlockSize（）返回字区大小（以字节形式）。
　　· engineGetIV（）返回初试化向量。它不用于RSA密码。
　　· engineGetKeySize（）返回一个特定的钥匙对象的钥匙大小。
　　· engineGetOutputSize（）以字节形式返回输出长度，输出缓冲器需要这个长度来保存下一个update或doFinal操作的结果，输入长度已假定。
　　· engineGetParameters（）返回这个密码运用的参数。
　　· engineSetMode（）设置密码的模式（加密或解密）。
　　· engineSetPadding（）设置这个密码的填充机制（当前只支持PKCS1填充）。
　　· engineWrap（）封装一个钥匙（未实现）。
　　· engineUnwrap（）解开一个钥匙（未实现）。

　　RSA加密过程需要公钥；RSA解密需要私钥。如果我们有权使用Microsoft钥匙库中的RSA私钥——即，私钥是可以输出的——那么就没必要在Microsoft本地代码中执行RSA密码操作。但在有些情况下（例如，如果我们运用一个加密了的智能卡），我们就无权使用私钥。如果私钥是不能输出的，我们必须用Microsoft本地代码进行RSA解密。

　　RSA密码在Windows本地代码中的实现很简单。本质的解密过程如下：

MSrsaDecrypt （jstring jpadalg,
jbyteArray jdata） {
CryptAcquireContext（
&hDecryptProv, alias, NULL,
PROV_RSA_FULL,0）；
CryptGetUserKey（hDecryptProv,
AT_KEYEXCHANGE, &hDecryptKey）；
CryptDecrypt（hDecryptKey, 0,
TRUE, 0, encryptblob, &ndata）；
return decryptblob；
}

　　加密几乎是一样的。因为RSA加密只需要公钥，加密模式可以在Java中执行。我选择在Windows本地代码中实现RSA加密和解密，因为这很容易。

　　RSA密码是一个美国政府控制的加密算法。如果你想将RSA cipher provider同Sun JCE结合起来运用，你必须创建一个JAR文件，用一个DSA钥匙签署它，然后添加一个由Sun Microsystems签发的证书。为了方便，我已经把所有的mscrypto-class文件放在了一个单一的包中（com.boyter.mscrypto）。在签署的JAR文件中，只需要有MSRSACipherProvider.class和MSRSACipherFactoryImpl.class。用来创建和签名JAR文件的Windows命令是：

jar cvf mscrypto.jar com
jarsigner -keystore keystore
-storepass foobar mscrypto.jar
jcesigner

　　你可以从“How to Implement a Provider for the Java Cryptography Extension 1.2.1.”（见资源）的第五步找到关于从Sun获取一个JCE代码签署的证书的说明。如果你想避免JCE的局限性（如美国政府的输出控制），你可以用一个clean-room式的实现环境（如BeeJCE）来代替JCE。我提供了一个称为msrsatest.java的程序，可以用来测试Microsoft 加密的RSA签名和RSA密码提供者。为此，你必须在Microsoft Windows中安装一个RSA私钥和证书。

　　有根据的运用理由

　　将Java安全特征同本地Microsoft Windows安全平台结合起来有许多好的理由，包括减少了的管理费用、CRL确认和与智能卡的兼容。将Java JCE同Windows证书和钥匙库结合起来的另一个理由是用来管理Java证书和钥匙库的Java工具很麻烦。Microsoft平台有一个更好的图形用户界面（GUI）用来管理Windows钥匙和证书库。你可以通过运行CERTMGR.EXT程序（与Windows平台SDK在一起）来启动GUI，或者你可以从IE窗口来启动：运用下拉菜单Tools | Internet Option，选择Content键，然后选择Certificates。

　　在将Microsoft 加密支持的KeyManager和TrustManager用于JSSE时，你不会有什么问题。Microsoft 加密支持的RSA Signature Provider和RSA Cipher Provider也可以运行，但不能用于JSSE。

已读帖子

新的帖子

被删除的帖子