这篇文章主要介绍了Mobile BI(移动商务智能)在安全网络通信中涉及的数字证书认证的背景知识以及相应实现的认证功能。

文章的具体内容包括：网络的基础知识（OSI模型、TLS），证书的信息（数字证书、证书的类别、证书文件扩展名、系统支持、相关概念），证书的认证（Server Certificate、Client Certificate - Download/Embedding/CSR、Certificate Pinning），iOS Coding，OpenSSL，引用。

网络基础知识

OSI 模型

OSI Model 即 Open Systems Interconnection Model 开放式系统互联通信参考模型

TLS

传输层安全协议 TLS Transport Layer Security 及其前身安全套接字层 SSL Secure Socket Layer 是一种安全协议，目的是为互联网通信提供安全及数据完整性保障，即保证“信息加密”、“数据完整”以及“身份认证”三方面的风险。

SSL 3.0 Google在2014年发布了3.0的设计缺陷，建议禁用此协议。在兼容SSL3.0的情况下，攻击者可以向TLS发送虚假错误提示，然后将安全连接降级到SSL3.0，然后利用此设计漏洞窃取敏感信息。

TLS 1.0 从技术上来看，与SSL 3.0类似，并包含可降级到SSL 3.0的实现。

TLS 1.1 于2006年发表，增加了对CBC攻击的保护（隐式IV被替换成显式IV，更改分组密码模式中的填充错误）等。

TLS 1.2 于2008年发表，基于TLS 1.1规范：

• 伪随机数可使用SHA-256替换MD5-SHA-1
• 密钥交换和协商 RSA
• 加密算法 AES
• 数据完整性 HMAC

TLS 1.3 仍是草案，持续加强安全等方面的标准。

与应用层无关，SSL/TLS是一个介于HTTP协议与TCP之间的一个可选层：

SSL协议可分为两层：SSL记录协议 SSL Record Protocol 建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持；SSL握手协议 SSL Handshake Protocol 建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等

TLS协议类似，由TLS记录协议 TLS Record 和 TLS 握手协议 TLS Handshake 组成，TLS记录协议位于某个可靠的传输协议（如TCP）之上。

握手协议
虽然非对称加密RSA可以确保网络上信息交换的安全性，但是由于RSA加密的速度较慢，所以并不适合直接加密传输数据，而一般只用于交换密钥，另外再使用对称加密AES高效的传输数据。

握手协议用来验证通信双方的身份并协商通信密钥：

客户端发出请求 Client Hello：

• 客户端发出信息包含：所支持的协议版本、加密算法、压缩方法，以及生产的一个随机数（用于生成对话密钥）

服务器回应 Server Hello：

• 服务器回应信息包括：确认支持的协议版本、加密算法，服务器生成的随机数（用于生成对话密钥），服务器证书
• 对服务器的一种认证：服务器证书，由数字证书认证机构CA审核后颁发的电子证书，包含一个私钥和公钥，公钥附在证书的信息中，另外证书还包含电子签名来确保证书的完整性和真实性，以及有效期。
• 对客户端认证：同样的对客户端也可以进行证书认证
• 随机数：客户端和服务端都需要使用这两个随机数来产生对话密钥 Master Secret

客户端回应 Certificate Verify：

• Client Key Exchange：如果需要对客户端进行验证，首先需要发送客户端证书以便服务器端来验证
• Certificate Verify，客户端验证通过后会获得服务器的公钥后，发送下列信息：第三个随机数（使用服务器公钥加密）、编码改变通知（后继信息使用协商的加密方法和密钥发送）、客户端握手结束通知（一般为发送内容的hash值，用来服务器校验）
• ChangeCipherSpec协议在数据包中就是一个字节的数据，用于告知服务端，客户端已经准备好。

服务器的最后回应 Server Finish：

• 服务器得到加密数据后使用私钥进行解密，并对数据进行验证，会使用跟客户端同样的方式生成 会话密钥 Session Secret
• ChangeCipherSpec 完成后同样发送，表示服务器也准备好
• 服务器端同样使用会话密钥加密一段Finish消息发送给客户端，以验证之前通过握手建立起来的安全通道是否成功。

几个密钥 Secret

• PreMaster Secret：是在客户端使用RSA等加密算法生成的。用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成Master Secret；在客户端使用服务器端的公钥对PreMaster Secret进行加密之后传送给服务器端，而服务器端使用私钥进行解密得到PreMaster Secret，这样两方都有一份相同的PreMaster Secret和随机数。
• Master Secret：根据上面提到的信息，客户端和服务器端都可以计算出相同的Master Secret，而这个将作为最终Session Key的Key Material（包含MAC，Encryption Key，IV等）的一部分信息。

证书的信息

数字证书

数字证书 Digital Certificate 即 Public Key Certificate/Identity Certificate 是用来证明公钥归属的一个电子证书：

A digital certificate certifies the ownership of a public key by the named subject of the certificate, and indicates certain expected usages of that key.

This allows others (relying parties) to rely upon signatures or on assertions made by the private key that corresponds to the certified public key.

X.509 定义了数字证书的格式标准，它的结构如下：

Certificate
  - Version Number
  - Serial Number
  - Signature Algorithm ID
  - Issuer Name
  - Validity period
    - Not Before
    - Not After
  - Subject name
  - Subject Public Key Info
    - Public Key Algorithm
    - Subject Public Key
  - Issuer Unique Identifier (optional)
  - Subject Unique Identifier (optional)
  - Extensions (optional)
    - ...
Certificate Signature Algorithm
Certificate Signature

证书的类别

TLS/SSL Server Certificate：用来验证服务器身份，包括是否符合"hostname"以及是否是可信任的"CA"颁发

TLS/SSL Client Certificate：用来验证客户端身份

Root Certificate：用来签发其他证书的自签名证书

Intermediate Certificate：用来签发其他证书的非自签名证书，它必须被其他中间证书或者根证书签发

Self-signed Certificate：这种证书拥有可以与它的发布者匹配的主题，以及可以通过它自己的公钥验证的签名

证书文件扩展名

证书一般有两种编码格式：

• DER Distinguished Encoding Rules：二进制格式
• PEM Privacy Enhanced Electronic Mail：Base64编码

证书会以不同的后缀文件出现：

• .pem 即Base64编码的DER证书
• .der, .cer, .crt 即二进制DER格式，不绝对，也可能使用PEM编码
• .p7b, .p7c 即PKCS#7结构，仅包含Certificate/CRL
• .p12 即 PKCS#12 "Public Key Cryptography Standards 12" 包含证书和私钥，私钥被密码保护
• .pfx 即PFX为PKCS#12的前身

系统支持

Mac和Windows都有专门的处理证书的地方，我们可以从中了解它们所支持的不同的格式和所包含的信息：

Mac: From Keychain Access, Save Certificate
- Certificate (.cer)
- Privacy Enhanced Mail (.pem)
- Certificate Bundle (.p7b)
- Personal Information Exchange (.p12)

Windows: From IE
- DER encoded binary X.509 (.CER)
- Base-64 encoded X.509 (.CER)
- Cryptographic Message Syntax Standard - PKCS #7 Certificates (.P7B)
  - Include all certificates in the certification path if possible
- Personal Information Exchange - PKCS #12 (.PFX)
  - Include all certificates in the certification path if possible
  - Delete the private key if the export is successful
  - Export all extended properties
- Microsoft Serialized Certificate Store (.SST)

相关概念

CA Certificate Authority/Certification Authority 是用来签发数字证书的可信任的第三方

Certificate Chain 是指一个证书列表链，通常第一个是CA证书，而最后一个是Self-signed Certificate

CSR Certificate Signing Request 证书签名请求，包含一个公钥

CRL Certificate Revocation List 证书吊销列表

KEY: 用来存放一个公钥或者私钥，非证书

JKS: Java Key Storage Java的专利

PKI: Public Key Infrastructure 公钥基础设施，支持公开密钥管理并能支持认证、加密、完整性和可追究性服务的基础设施

证书的认证

从上面的介绍我们已经可以了解网络通信安全的核心在于SSL安全协议，而SSL的核心在于证书的验证。所以这里就介绍一下在Mobile BI安全网络实施过程中涉及的关于证书认证的功能。

Server Certificate

这是最常见的服务器身份验证，交换密钥，确保数据加密安全传输。使用CSR保留私钥，使用公钥申请，CA认证。

iOS中会收到NSURLAuthenticationMethodServerTrust的Challenge，而一般而言，我们不需要在应用中处理，而直接通过在设备上安装根证书来自动验证服务器证书。

Issue: Server Certificate doesn’t work in iOS8.1
这是因为我们默认的证书不是一个完整的证书链，而仅仅是一个单独的证书，在iOS8.1中需要使用完整的证书链来认证：

iOS8 is less permissive as iOS7

• Add the intermediate certificates in the server certificate and got it working
• in iOS8, add intermediate certificates in the server certificate and keep only the root in the device

Client Certificate - Download

相应的对客户端的认证，需要客户端提供一个证书，在与服务器进行握手协议时发送给服务器认证。

这个功能是从应用中向证书服务器请求获取一个证书，而证书服务器会生成一个PKCS#12文件发送给应用，客户端下载证书后会保存在Keychain中。这种方式的缺点也显而易见：私钥需要通过网络传递给客户端，并且客户端就这么无验证的接受一个证书也可能存在风险，比如中间人攻击这种。

Issue：Handshake in Apache
这个问题的表现是在一个WebView中无法处理Client Certificate Challenge，一般情况下，当我们回答一次后就完成了，但是这个问题却表现为持续收到来自 Apache Server的Challenge，同样的问题在 Tomcat Server中却不存在。

这是因为 Apache Server采用了更加严格的握手协议，对于客户端证书，它的默认配置即为每次连接都会要求验证。对于这个问题，我们需要修改httpd.conf的配置 SSLSessionCache dbm:/var/cache/apache2/sslcache

Client Certificate - Embedding

这是使用客户端证书的另一种方法，即默认客户端证书嵌入安装包，使用Plist配置密码，或者运行时输入密码来提取证书，而不需要从证书服务器上下载。这种方式的缺点也很明显：不同的设备会使用同一个证书。

Issue：Certificate Chain

使用Client Certificate Chain认证，在Tomcat 6/7 中正常，但在 Tomcat 5.5 中会失败，5.5需要使用单独的证书。

Client Certificate - CSR

我们可以看到上面提到的 Download/Embedding 方式在安全性上都有问题，所以相应的，CSR方式：设备自己生成CSR，保留私钥，而将公钥证书发送到证书服务器获取签名认证后使用。这种方式既保证了私钥不会通过网络传送，并且不同的设备将拥有不同的客户端证书。

Certificate Pinning

在我们验证服务器证书时，即使它可以被可信任CA认证，也可能存在某种风险，比如CA认证的疏漏，或者遭遇到的中间人攻击。所以更安全的方式是我们限定认证某个范围内的证书：这可以是某个特定的证书或者更小范围的根证书。

一般而言，当应用获取到服务器证书后，客户端需要使用可信任的验证数据 "trusted validation data" 来验证，这种数据可以为下面两种形式之一：

a trusted copy of that certificate
a trusted hash or fingerprint of that certificate or the certificate's public key

在Mobile BI中，Pinning的过程分为三步：TLS verification, Domain Evaluation, Pinning Verification。需要注意的是：

For each certificate we extract the SPKI and hash it with SHA-256 (hash is aka Fingerprint)

这里的SPKI 即 Subject Public Key Info，包含了 "public key"以及 "public key algorithm"。你可能注意到，这里没有直接使用证书，而是使用了证书里面的SPKI，这是因为：CA证书经常会被重新签发不够稳定；多个证书可能具有相同的公钥和主题名等，但是有效期却不同，但事实上它们还是可被认证的同一个证书。所以我们使用了不变的且可代表证书特性的SPKI。

我们需要从证书中提取SPKI：

Extracting public key

• SecTrustCopyPublicKey(trust) provided by iOS
• X509_get0_pubkey_bitstr(certificateX509) provided by OpenSSL

Extracting public key algorithm

• We can use X509_get_pubkey(certificateX509) to get an EVP_PKEY object first
• Then use its ->type variable (should be an integer) to decide the type of algorithm.
• For example, if the type is 6, the algorithm should be RSA Encryption

Pinning大热是由Google前两年一次更新导致：Google列出了可被信任的白名单 Verisign, Google Internet Authority, Equifax and GeoTrust，对于其他CA签发的证书不再认可。

iOS Coding

关于id的引用SecIdentityRef：

@abstract CFType representing an identity, which contains a SecKeyRef and an associated SecCertificateRef
typedef struct CF_BRIDGED_TYPE(id) SECTYPE(SecIdentity) *SecIdentityRef;

代表X.509证书的引用SecCertificateRef：

@abstract CFType representing a X.509 certificate.
typedef struct CF_BRIDGED_TYPE(id) SECTYPE(SecCertificate) *SecCertificateRef;

获得证书链中的证书数目的方法SecTrustGetCertificateCount：

@abstract Returns the number of certificates in an evaluated certificate chain.
CFIndex SecTrustGetCertificateCount(SecTrustRef trust)

从证书链中获取证书的方法SecTrustGetCertificateAtIndex，得到SecCertificateRef的证书引用：

@abstract Returns a certificate from the trust chain.
SecCertificateRef SecTrustGetCertificateAtIndex(SecTrustRef trust, CFIndex ix)

从keychain中取得证书引用SecItemCopyMatching，可转换成SecIdentityRef引用：

@abstract Returns one or more items which match a search query.
OSStatus SecItemCopyMatching(CFDictionaryRef query, CFTypeRef * __nullable result)

从SecIdentityRef引用获取证书引用的方法SecIdentityCopyCertificate：

@abstract Returns a reference to a certificate for the given identity reference.
OSStatus SecIdentityCopyCertificate(
            SecIdentityRef identityRef,
            SecCertificateRef * __nonnull CF_RETURNS_RETAINED certificateRef)

导入证书文件的方法SecPKCS12Import：

@abstract Imports the contents of a PKCS12 formatted blob.
OSStatus SecPKCS12Import(CFDataRef pkcs12_data, CFDictionaryRef options, CFArrayRef * __nonnull items)

获取DER格式的X.509证书的方法SecCertificateCopyData：

@abstract Return the DER representation of an X.509 certificate.
CFDataRef SecCertificateCopyData(SecCertificateRef certificate)

生成哈希值的方法CC_SHA256：

extern unsigned char *CC_SHA256(const void *data, CC_LONG len, unsigned char *md)

证书的验证SecTrustEvaluate

@abstract Evaluates a trust reference synchronously.
OSStatus SecTrustEvaluate(SecTrustRef trust, SecTrustResultType * __nullable result)

OpenSSL

SSL是一种规范，而OpenSSL是SSL的一个实现，顺便还提供了相应的工具软件。之前曾出现过“心脏出血漏洞”，需要使用最新的版本来避免。

OpenSSL支持多种不同的加密算法

加密：AES, Blowfish, Camellia, SEED, CAST-128, DES, IDEA, RC2, RC4, RC5, Triple DES, GOST 28147-89[3]

散列函数：MD5, MD2, SHA-1, SHA-2, RIPEMD-160, MDC-2, GOST R 34.11-94

公开密钥加密：RSA, DSA, Diffie–Hellman key exchange, Elliptic curve, GOST R 34.10-2001

我们开发中涉及的OpenSSL的API：从二进制数据中获取一个DER格式的X509证书d2i_X509，并提取public key以及algorithm：

X509 *d2i_X509_AUX(X509 **a, const unsigned char **pp, long length);
ASN1_BIT_STRING *X509_get0_pubkey_bitstr(const X509 *x);
EVP_PKEY *X509_get_pubkey(X509 *x);

引用

Wikipedia OSI Model

Wikipedia TLS

SSL/TLS原理详解

Wikipedia Certificate