這篇文章描述了如何使用Java密碼體系結構 （JCA），該體系結構使您可以在應用程序中使用密碼服務。

Java密碼體系結構服務

JCA提供了許多加密服務，例如消息摘要和簽名 。

這些服務可以通過特定于服務的API來訪問，例如MessageDigest和Signature 。

密碼服務抽象了不同的算法。 例如，對于摘要，可以使用MD5或SHA1 。 您可以將算法指定為加密服務類的getInstance()方法的參數：

MessageDigest digest = MessageDigest.getInstance("MD5");

您可以在“ JCA 標準算法名稱文檔”中找到算法參數的值。

一些算法具有參數。 例如，生成私鑰/公鑰對的算法將把密鑰大小作為參數。 您可以使用initialize()方法指定參數：

KeyPairGenerator generator = KeyPairGenerator.getInstance("DSA");
generator.initialize(1024);

如果不調用initialize()方法，則將使用某些默認值，該默認值可能是您想要的，也可能不是。

不幸的是，用于初始化的API在服務之間并非100％一致。

例如， Cipher類將init()與指示加密或解密的參數一起使用，而Signature類將initSign()用于簽名， initVerify()用于驗證。

Java密碼體系結構提供程序

JCA通過提供程序系統使您的代碼獨立于特定密碼算法的實現。

提供商根據可配置的首選項順序進行排名（請參見下文）。 最佳優先級是1，次佳是2，依此類推。優先級順序允許JCA選擇實現給定算法的最佳可用提供程序。

另外，您可以在getInstance()的第二個參數中指定特定的提供程序：

Signature signature = Signature.getInstance("SHA1withDSA", "SUN");

默認情況下，JRE附帶了來自Oracle的一堆提供程序 。 但是，由于歷史上的出口限制，這些并不是最安全的實現。 要獲得更好的算法和更大的密鑰大小，請安裝Java密碼學擴展無限強度管轄權策略文件 。

更新 ：請注意，以上聲明對Oracle JRE是正確的。 OpenJDK沒有相同的限制 。

使您可以對密碼學進行配置

您應始終確保應用程序使用的加密服務是可配置的。

如果這樣做，則可以在不發布補丁的情況下更改密碼算法和/或實現。

當對（一種實現）算法有新的攻擊時，這特別有價值。

JCA使配置加密的使用變得容易。

getInstance()方法同時接受算法的名稱和實現該算法的提供程序的名稱。 您應該從某種配置文件中讀取算法參數的值和所有值。

還要確保將代碼DRY保留在一個地方并實例化加密服務。

檢查所請求的算法和/或提供程序是否實際可用。

當給定的算法或提供程序不可用時， getInstance()方法將引發NoSuchAlgorithmException ，因此您應該捕獲該異常。 然后最安全的選擇是失敗，并請他人確保系統配置正確。 如果在配置錯誤的情況下仍然繼續，則可能會導致系統安全性低于要求。

請注意， Oracle建議不要指定提供程序 。 它們提供的原因是，并非所有提供程序都可以在所有平臺上使用，并且指定提供程序可能意味著您錯過了優化。

您應該權衡這些不利因素和易受攻擊的風險。

在您的應用程序中部署具有已知特征的特定提供程序可能會消除Oracle提到的缺點。

添加加密服務提供商

提供程序系統是可擴展的，因此您可以添加提供程序。

例如，您可以使用開源Bouncy Castle或商業RSA BSAFE提供程序。

為了添加提供程序，必須確保其jar對應用程序可用。 為此，您可以將其放在類路徑中。

另外，您可以通過將其放置在$JAVA_HOME/lib/ext目錄中來使其成為已安裝的擴展 ，其中$JAVA_HOME是JDK / JRE發行版的位置。

兩種方法之間的主要區別在于，默認情況下， 已授予安裝的擴展所有權限 ，而classpath上的代碼則未被授予 。 當您的代碼（的一部分）在沙盒中運行時，這非常重要。

某些服務（例如Cipher ）要求對提供者jar進行簽名 。

下一步是在JCA提供者系統中注冊提供者。 最簡單的方法是使用Security.addProvider() ：

Security.addProvider(new BouncyCastleProvider());

您還可以使用Security.insertProviderAt()方法設置提供者的優先順序：

Security.insertProviderAt (new JsafeJCE(), 1);

這種方法的一個缺點是，它將代碼耦合到提供程序，因為您必須導入提供程序類。 在像OSGi這樣的模塊化系統中，這可能不是重要的問題。

需要注意的另一件事是代碼需要SecurityPermission以編程方式添加提供程序。

通過將注冊項添加到java.security屬性文件（可在$JAVA_HOME/jre/lib/security/java.security找到），還可以通過靜態注冊將提供程序配置為您環境的一部分：

security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=sun.security.provider.Sun

該文件中的屬性名稱以security.provider.開頭security.provider. 并以提供者的偏好結束。 該屬性值是實現Provider的類的完全限定名稱。

實施您自己的加密服務提供商

不要這樣做 。 您會弄錯它，并且容易受到攻擊。

使用加密服務提供者

提供程序的文檔應告訴您將哪個提供程序名稱用作getInstance()的第二個參數。 例如，Bouncy Castle使用BC ，而RSA BSAFE使用JsafeJCE 。

大多數提供程序都有自定義API以及符合JCA的API。 請勿使用自定義API，因為那樣將無法配置所使用的算法和提供程序。

并非所有算法和實現都是相同的

重要的是要注意，不同的算法和實現具有不同的特性，這些特性或多或少會使它們適合您的情況。

例如，某些組織僅允許使用經過FIPS 140-2認證或在NSA Suite B加密算法列表中的算法和實現。

始終確保您了解客戶的加密需求和要求。

在OSGi環境中使用JCA

getInstance()方法是使用服務提供商接口 （SPI）的工廠方法 。 這在OSGi世界中是有問題的，因為OSGi違反了SPI框架關于存在單個類路徑的假設。

另一個潛在的問題是，JCA需要對一些jar進行簽名。 如果這些罐子不是有效的OSGi捆綁包，則不能通過bnd來運行它們，因為這樣會使簽名無效。

幸運的是，您可以用一塊石頭殺死兩只鳥。 將提供程序jar放在主程序（即啟動OSGi框架的程序）的類路徑中。

然后使用org.osgi.framework.system.packages.extra系統屬性從OSGi系統捆綁包導出提供程序包。 這將使系統捆綁包導出該軟件包。

現在，您可以簡單地在包中的提供程序Import-Package上使用Import-Package 。

還有其他的選擇 ，因為如果你不能使用上述方案解決這些問題。

參考： Secure Software Development博客上的JCG合作伙伴 Remon Sinnema提供了在Java應用程序中使用加密的信息 。

翻譯自: https://www.javacodegeeks.com/2012/12/test-using-cryptography-in-java-applications.html