[dev][ipsec][dpdk] strongswan/dpdk源码分析--(七)ipsec算法配置过程

1 简述

storngswan的配置里用一种固定格式的字符串设置了用于协商的预定义算法。在包协商过程中strongswan将字符串转换为固定的枚举值封在数据包里用于传输。

协商成功之后，这组被协商选中的枚举值会通过netlink接口以xfrm定义好的字符串形式，传递给内核，内核再将字符串转换成pfkey定义的枚举值，最终进行加密设置。

DPDK的话，也有其统一的一组枚举值的抽象。在调用不同的cryptodev pmd时，会想这组值转换为对应的值或操作，如转变成openssl对应的API调用。

见下图：

 

1.1 名词解释

ICV：ICV有两种翻译，两种解释：Integrity Check Value， initial chaining vector。

通常我们把IV理解为： initial chaining vector； 把ICV理解为：Integrity Check Value

 

2 strongswan

在strongswan的配置里，算法是可以通过字符串进行配置的，这样的字符串如下：

esp_proposals = aes128-sha384-curve25519-esn,aes128-sha384-esn

逗号分隔的是两个套装。横线分隔的是不同的阶段，加密-认证-协商-是否esn

手册里有详细的解释：man  ipsec.conf

The notation is encryption-integrity[-dhgroup][-esnmode].

上面提到的是字符串格式的定义。具体的字符串到数据包中的值的定义，是在RFC中约定的，见文档：

https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

https://wiki.strongswan.org/projects/strongswan/wiki/IKEv1CipherSuites

 

3 netlink/xfrm

为了使用xfrm的统一接口，strongswan的netlink模块做了一次转换

见代码：kernel_netlink_ipsec.c

 

4 linux kernel

kernel的xfrm模块将netlink plugin传递过来的string转换成pfkey中定义的枚举。

xfrm部分的代码：xfrm_algo.c

pfkey中的枚举定义：linux/pfkeyv2.h

 

5 dpdk

dpdk中cryptodev同样也有自己的封装定义，按类别分为对称，非对称等。

算法的枚举值定义在这个地方： rte_crypto_sym.h

5.1 关键API：

int
rte_cryptodev_sym_session_init(uint8_t dev_id,
            struct rte_cryptodev_sym_session *sess,
            struct rte_crypto_sym_xform *xforms,
            struct rte_mempool *mempool);

如，开篇那个图，所有的算法都是通过这个API注册进dpdk的。

在这个数据结构里，它是一个串在一起的链表，将加密算法和消息认证码算法串在一起作为参数传递。

struct rte_crypto_sym_xform {
    struct rte_crypto_sym_xform *next;
    /**< next xform in chain */
    enum rte_crypto_sym_xform_type type
    ; /**< xform type */
    RTE_STD_C11
    union {
        struct rte_crypto_auth_xform auth;
        /**< Authentication / hash xform */
        struct rte_crypto_cipher_xform cipher;
        /**< Cipher xform */
        struct rte_crypto_aead_xform aead;
        /**< AEAD xform */
    };
};

接下来逐个讨论加密，消息认证和aead的结构：

5.2 加密：

struct rte_crypto_cipher_xform {
    enum rte_crypto_cipher_operation op;   // 加密还是解密
    enum rte_crypto_cipher_algorithm algo;  // 哪一种加密算法
    struct {
        uint8_t *data;  
        uint16_t length;
    } key;                                 // 秘钥及其长度
    struct {
        uint16_t offset;                  // 对于块分组加密这里是初始化向量的起点（rte_crypto_op??），对于CRT分组加密，这里是counter， CCM的时候，第一个字节保留，第二个自己用来写入nonce
        uint16_t length;                  // CRT的时候等于block length， CCM的时候是nonce的长度，7-13之间。
    } iv;
}；

5.3 消息认证：

struct rte_crypto_auth_xform {
    enum rte_crypto_auth_operation op;
    enum rte_crypto_auth_algorithm algo;
    struct {
        uint8_t *data;
        uint16_t length;    // 必须小于或等于 block size
    } key;
    struct {
        uint16_t offset;    // 初始化向量，需要八字节对齐
        uint16_t length;
    } iv;
    uint16_t digest_length;        // hash算法的截断长度
};

5.4 AEAD：

struct rte_crypto_aead_xform {
    enum rte_crypto_aead_operation op;
    enum rte_crypto_aead_algorithm algo;
    struct {
        uint8_t *data;
        uint16_t length;
    } key;
    struct {
        uint16_t offset;      // CCM的时候，第一个字节保留，第二个字节用来写入nonce
        uint16_t length;      // CCM的时候，nonce的长度，7-13之间
    } iv;
    uint16_t digest_length;
    uint16_t aad_length;      // 附加验证长度？？
};

 

前文的IV offset与一个结构体相关struct rte_crypto_op cop

这个结构体是作为参数传递给下面api的

static inline int
rte_crypto_op_attach_sym_session(struct rte_crypto_op *op,
        struct rte_cryptodev_sym_session *sess)

在不使用rte_ipsec库的情况下，op中的一些值需要用户关心。使用rte_ipsec库的时候，一般不用关心。rte_ipsec将其封装在内部处理。

 

6 rte_ipsec

在rte_ipsec库中，围绕这前文提到的加密算法及其参数主要做了以下三方面的动作：

1. 通过API rte_cryptodev_sym_session_init()将算法和参数下发给底层的pmd设备。

2. 为每一个需要加解密的报文准备op(rte_crypto_op)，然后attach进session里边。通过这个函数esp_inb_tun_cop_prepare() [librte_ipsec/sa.c]

3. 为每一个需要加解密的报文准备数据包的esp封装。通过这个函数esp_inb_tun_pkt_prepare() [librte_ipsec/sa.c]

所以在整个rte_ipsec库的使用过程中。只有保证以上3者的数据和设置可以正常配合，便能保证成功使用。

详见：[dev][dpdk][crypto] dpdk加解密设备与IPSEC

（另外：在分析rte_ipsec的源码过程中，并没有发现对API rte_crypto_op_attach_sym_session的调用。奇怪。。。）

 

7 strongswan libipsec

基于我们对于dpdk库的分析，此刻已经了解到，一个算法的基本构成单元，是由方法本身及一组参数构成的。参数为：key长度，iv长度，digest长度，盐等组成的。

现在回到strongswan，它的代码里边除了对rfc中各个函数的定义以为，一定还拥有这些参数值与办法定义直接的对应关系。

前文，我们已经知道与内核通信时的netlink plugin中对这部分参数在传递过程中进行了定义，但由于内核的支持有限，所以也并不完整。同时，strongswan也提供了一个用户态的esp实现，

叫做libipsec，根据文档中的描述，该库对rfc中的所有算法实现了完整的支持。接下来我们对这个库进行简要的分析。

 

进入这部分功能的入口在，函数 create_traditional() [/strongswan.git/src/libipsec/esp_context.c] 中。

1. create_traditional() 会调用函数crypto_factory.c::create_crypter()

2. 之后会进入加解密plugin的create函数

METHOD(crypto_factory_t, create_crypter, crypter_t*,
    private_crypto_factory_t *this, encryption_algorithm_t algo,
    size_t key_size)
{
    。。。 。。。
    enumerator = this->crypters->create_enumerator(this->crypters);
    while (enumerator->enumerate(enumerator, &entry))
    {
            。。。 。。。
            crypter = entry->create_crypter(algo, key_size);
            。。。 。。。
    }
    。。。 。。。
}

红色字体是一个函数指针，是由下文中的这个宏，注册进去的。

METHOD(plugin_t, get_features, int,
    private_aes_plugin_t *this, plugin_feature_t *features[])
{
    static plugin_feature_t f[] = {
        PLUGIN_REGISTER(CRYPTER, aes_crypter_create),
                        ... ...
    };
        ... ...  
}

 

故，逐个分析每一个算法plugin的实现，将能够得到具体的参数数值。

 

8 RFC

一些关于算法参数的细节除了可以查看7中的实现以外，我们还可以查看RFC。

 所有RFC的列表可以从第二章的两个链接关联出来，便能针对不同的算法找到它所对应的RFC文件了。

在RFC中有对各种算法的参数特别详细的描写。

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml

https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml

https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xhtml