腾讯Kona国密套件：从基础算法到安全协议
腾讯Kona国密套件（Tencent Kona SM Suite）基于JDK的标准Service Provider Interface（SPI）实现了从基础算法簇，到公钥基础设施（PKI），再到安全通信协议的全链路国密特性。该套件已在GitHub上开源：https://github.com/Tencent/TencentKonaSMSuite（点击阅读原文）
腾讯Kona国密套件包含四个Java Security Provider：
KonaCrypto，它是一个Java Cryptography Extension（JCE）实现，遵循标准的Java Cryptography Architecture（JCA）框架实现了国密基础算法SM2，SM3和SM4。
KonaPKIX，它实现了国密证书的解析及其证书链验证，并可加载和创建包含国密证书的密钥库（Key Store）文件。
KonaSSL，它实现了中国的传输层密码协议（TLCP），并遵循RFC 8998规范将国密基础算法应用到了TLS 1.3协议中。
Kona，它没有直接实现任何功能，而是将KonaCrypto，KonaPKIX和KonaSSL中的特性进行了简单的封装，以方便用户仅使用这一个Provider就能够调用上述三个Provider中的全部功能。一般地，建议使用这个Provider。
许可协议
腾讯Kona国密套件使用的许可协议是GNU GPL v2.0 license with Classpath Exception，这也正是OpenJDK使用的许可协议。
系统要求
操作系统
腾讯Kona国密套件为纯Java编写，可以支持任何能够运行JDK的操作系统平台，也能够支持Android平台。
JDK版本
支持JDK的全部三个长期支持（LTS）版本，即8，11和17。
值得注意的是，任何JCE实现必须要先获得由Oracle颁发的JCE代码签名证书才能运行在Oracle JDK上。而腾讯Kona国密套件已经取得了该证书，并且它的jar文件均使用该证书进行了签名，所以该套件也可以运行在Oracle JDK上。
不过，我们非常期待您能选择腾讯的OpenJDK发行版，即Tencent Kona JDK，其提供了8，11和17三大LTS版本，并支持Linux，macOS和Windows等主流操作系统，以及x86_64和aarch64等主流CPU架构。Tencent Kona JDK依托腾讯的海量生产级实践，针对大数据，云计算，机器学习等场景进行了大量的定制优化。
构建
腾讯Kona国密套件使用Gradle进行构建，其脚本使用Kotlin DSL。该Gradle项目包含有四个子模块：kona-crypto，kona-pkix，kona-ssl和kona-provider，它们分别对应于四个Provider：KonaCrypto，KonaPKIX，KonaSSL和Kona。
构建该项目的一个典型方法就是在该项目的根目录下执行命令：
gradle build它会编译源代码，并执行单元测试，最后制作出jar文件。也可以仅构建某个子模块，比如像下面这样：
gradle :kona-pkix:build安装
腾讯Kona国密套件的所有制品（jar文件）都已经上传到了Maven中央仓库。一般地，只需要在项目的构建脚本中把它们声明为依赖就可以了。比如，在Gradle的构建脚本中可以有如下的依赖声明：
repositories {mavenCentral()}dependencies {implementation("com.tencent.kona:kona-crypto:1.0.4")implementation("com.tencent.kona:kona-pkix:1.0.4")implementation("com.tencent.kona:kona-ssl:1.0.4")implementation("com.tencent.kona:kona-provider:1.0.4")}
注意，并不一定要将所有的Provider都加到类路径中，请根据实际需求去声明依赖。例如，若只需要使用国密的基础算法，且想统一地使用Provider名称Kona时，那么依赖声明可能就像下面这样：
dependencies {implementation("com.tencent.kona:kona-crypto:1.0.4")implementation("com.tencent.kona:kona-provider:1.0.4")}
加载Provider
在使用腾讯Kona国密套件提供的特性之前，需要先加载它的Provider。推荐加载KonaProvider，如下所示：
Security.addProvider(new KonaProvider());上述语句会将KonaProvider加到Provider列表的最后一位，其优先级为最低。如有必要，也可以将它插入到列表的指定位置，如下所示：
Security.insertProviderAt(new KonaProvider(), n);其中n的值越小，优先级越高，最小可为1。
特性
下面将会介绍腾讯Kona国密套件的主要特性：
基础算法簇
腾讯Kona国密套件中的KonaCrypto实现了国密的基础算法簇，包括SM2，SM3和SM4。
SM2
SM2是一个基于椭圆曲线（ECC）的非对称加密算法。实现该算法需要遵循如下的中国国家标准：
GB/T 32918.1-2016 第1部分：总则
GB/T 32918.2-2016 第2部分：数字签名
GB/T 32918.3-2016 第3部分：密钥交换协议
GB/T 32918.4-2016 第4部分：公钥加密算法
GB/T 32918.5-2017 第5部分：参数定义
KonaCrypto实现了JDK定义的KeyPairGeneratorSpi，SignatureSpi，CipherSpi和KeyAgreementSpi接口，以提供SM2密钥对生成，SM2签名，SM2加密和SM2密钥交换等特性。使用这些算法与使用JDK自带的其它密钥对生成算法（如ECKeyPairGenerator），签名算法（如SHA256withECDSA），非对称加密算法（如RSA）和密钥协商算法（如ECKeyAgreement）是非常相似的。
需要特别强调的是，SM2密钥交换协议与通常的ECDH密钥协商有很大的不同。SM2密钥交换协议要求双方各有两个密钥对：一个是长期密钥对，一般认为它来源于证书所使用的密钥对；另一个是短期密钥对，相当于通常的ECDHE算法使用的即时（Ephemeral）密钥对。另外，每一方还需要有各自的ID，如果没有的话，就使用默认的1234567812345678。另外，SM2密钥交换协议还要求区分是哪一方首先发起的交换，这一方被称为发起方（Initiator），另一方则为响应方（Responder）。
SM3
SM3是一个密码学安全的哈希算法。实现该算法需要遵循如下的中国国家标准：
GB/T 32905-2016：SM3密码杂凑算法
KonaCrypto实现了JDK定义的MessageDigestSpi和MacSpi接口，以提供SM3哈希和SM3HMac消息验证码等算法。使用这些算法与使用JDK自带的其它哈希算法（如SHA-256）和消息验证码算法（如HmacSHA256）是非常相似的。
SM4
SM4是一个分组加密算法。实现该算法需要遵循如下的中国国家标准：
GB/T 32907-2016：SM4分组密码算法
KonaCrypto为SM4支持了四种分组操作模式：
CBC（Cipher Block Chaining），密码块链接模式
CTR（Counter），计数器模式
ECB（Electronic codebook），电子密码本模式
GCM（Galois/Counter Mode），伽罗瓦/计数器模式。
另外，还为CBC和ECB这两种操作模式实现了PKCS#7填充规范。
那么，支持了如下的Cipher参数组合（Transformation）：
SM4/CBC/NoPadding：使用CBC分组操作模式，不使用填充。明文或密文的长度必须是16字节的整数倍。
SM4/CBC/PKCS7Padding：使用CBC分组操作模式，且使用PKCS#7填充。明文或密文的长度可以不是16字节的整数倍。
SM4/CTR/NoPadding：使用CTR分组操作模式，不使用填充。明文或密文的长度可以不是16字节的整数倍。
SM4/ECB/NoPadding：使用ECB分组操作模式，不使用填充。明文或密文的长度必须是16字节的整数倍。
SM4/ECB/PKCS7Padding：使用ECB分组操作模式，且使用PKCS#7填充。明文或密文的长度可以不是16字节的整数倍。
SM4/GCM/NoPadding：使用GCM分组操作模式，不使用填充。明文或密文的长度可以不是16字节的整数倍。
为了提供上述特性，KonaCrypto实现了JDK定义的CipherSpi接口。使用SM4算法与使用JDK自带的其它分组加密算法（如AES）是非常相似的。
对于KonaCrypto的具体用法，请参见该GitHub项目中kona-crypto子模块的README和示例：
kona-crypto/README_cn.md
kona-crypto/src/test/java/com/tencent/kona/crypto/provider。
公钥基础设施（PKI）
腾讯Kona国密套件中的KonaPKIX基于JDK的Public Key Infrastructure（PKI）特性实现了对使用国密算法（SM2椭圆曲线和SM3withSM2签名算法）的X.509证书的解析，证书链验证，以及密钥库文件的读取与创建。在证书链验证中，还支持了证书吊销列表（CRL）和在线证书状态协议（OCSP）特性。为密钥库文件支持了标准的PKCS#12与JDK独有的JKS这两种格式。
为了提供上述特性，KonaPKIX实现了JDK定义的CertificateFactorySpi，KeyStoreSpi，CertPathBuilderSpi和SignatureSpi等接口。
对于KonaPKIX的具体用法，请参见该GitHub项目中kona-pkix子模块的README和示例：
kona-pkix/README_cn.md
kona-pkix/src/test/java/com/tencent/kona/pkix/demo
安全通信协议
腾讯Kona国密套件中的KonaSSL综合地利用了上面的国密基础算法与PKI特性，实现了中国的传输层密码协议（TLCP）和国际的RFC 8998规范。
传输层密码协议（TLCP）
TLCP是中国基于TLS 1.1和1.2协议定制而成的协议，对应的中国国家标准为：
GB/T 38636-2020：传输层密码协议
该协议与TLS协议的最重大区别，就是要求通信端提供两个证书：认证证书和加密证书。其中认证证书与TLS协议使用的证书功能类似，用于对通信端的身份进行验证。而加密证书则为TLCP协议独有，它只会用于密钥交换。
KonaSSL除了支持TLCP协议的"双证书"模式，还实现了它定义的密码套件ECC_SM4_GCM_SM3（0xE053），ECC_SM4_CBC_SM3（0xEC13），ECDHE_SM4_GCM_SM3（0xE051）和ECDHE_SM4_CBC_SM3（0xE011）。需要了解的是，当使用ECDHE密码套件时，客户端也必须提供双证书，这是SM2密钥交换算法所要求的，也是与TLS协议中的ECDHE密码套件的一个明显区别。
KonaSSL的TLCP实现不仅支持完整握手（Full Handshaking），也支持会话重用（Session Resumption）。而且不仅支持了传统的基于Session ID的会话重用，还支持了较新的基于Session Ticket的会话重用。后者会显著地减小服务端的压力，所以它也是KonaSSL的默认会话重用模式。
KonaSSL还为TLCP实现了一些重要的TLS扩展，如，服务器名称指示（SNI），它会帮助服务器选择正确的证书；应用层协议协商（ALPN），它会用于在握手时协商使用HTTP/2协议。
RFC 8998
RFC 8998规范将国密算法要素应用到了TLS 1.3协议中。KonaSSL实现了该规范定义的椭圆曲线curveSM2（41），签名机制sm2sig_sm3（0x0708）和密码套件TLS_SM4_GCB_SM3（0x00C6）。
为了提供上述特性，KonaSSL实现了JDK定义的SSLContextSpi等接口。为了能利用上KonaSSL实现的国密安全通信协议特性，其关键点就是让JDK的SSLSocket或SSLEngine能利用上KonaSSL实现的SSLContext实例。
上述安全通信协议的实现能够与其它方的实现，如蚂蚁集团的铜锁（原BabaSSL）和江南天安的TASSL，基于TLCP和TLS 1.3协议进行安全通信，这表明KonaSSL的实现是符合规范的。KonaSSL还能够与主流的Java组件，如Jetty，Netty和Apache Http Client，进行集成。
对于KonaSSL的具体用法，请参见该GitHub项目中kona-ssl子模块的README和示例：
kona-ssl/README_cn.md
kona-ssl/src/test/java/com/tencent/kona/ssl/demo
质量与安全
作为一款安全领域的基础组件，腾讯Kona国密套件始终高度重视代码质量，并对安全漏洞执零容忍态度。
腾讯Kona国密套件的基础代码来源于OpenJDK的security-libs模块，故其代码风格与OpenJDK保持一致。该套件一直密切跟踪OpenJDK前沿版本中相关模块的代码变化，实时地将其中的缺陷修复和代码改进移植进来，以确保该套件的代码能够紧跟OpenJDK的演进步伐。
特别地，OpenJDK每个季度发布的Critical Patch Update版本都会公布一批安全缺陷的修复。腾讯Kona国密套件也会立即对其中相关的安全缺陷的修复进行移植，以在最短时间内堵上安全漏洞。
除了时刻关注OpenJDK的缺陷与漏洞修复，我们也会自主地进行代码扫描与安全测试。比如，我们较早地发现了BouncyCastle的SM2加密死循环问题，并立即在自有代码中进行了规避。待BouncyCastle 1.72修复了该缺陷之后，我们也第一时间进行了升级。
近期规划
在腾讯Kona国密套件的初始版本中，国密基础算法完全依赖于开源的BouncyCastle。但我们正在逐步地重新开发这些算法，以期获得更好的性能，安全性和代码质量。当前最新的1.0.4版已经重新实现了SM2的KeyPairGenerator和 KeyAgreement，SM3的MessageDigest和HMac，以及SM4的Cipher。后续还会重新实现SM2的Cipher和Signature。在不久的未来，该套件将会完全摒弃BouncyCastle。