代码之美

标签： IPSec

  • 加密算法中的随机数

    • TRNG
      真随机数生成器，将随机的源作为输入，称为熵源。熵源可以是CPU温度，放射源，噪音等。Linux中/dev/random就是一个TRNG。使用TPM2.0模块也可以产生真随机数。
    • PRNG
      伪随机数生成器，将种子作为输入，使用确定算法产生位输出序列，输出仅和种子有关，用于产生不限长位流的算法。线性同余法，BBS就是常见的PRNG。
    • CPRNG
      密码安全伪随机数生成器，又称作确定性随机比特生成器(DRBG)。因为有些RNG生成的随机数具有可预测性，不能用于密码学，比如线性同余法。常用的CPRNG有NIST定义的Hash_DRBG,HMAC_DRBG,CTR_DRBG和以经废除的Dual_EC_DRBG以及微软的CryptGenRandom函数。大多数的CSPRNG结合使用来自OS的熵与高质量的PRNG。
    • PRF
      伪随机函数，PRF用于产生某个固定长度的伪随机比特串。PRF不是随机数生成器，而是给定输入返回一个看似随机的结果，如果输入相同输出也是相同的。通常用于密钥派生，比如通过多种来源作为种子，然后生成固定长度的密钥。常用的PRF是HMAC簇算法。IPsec和TLS中都需要配置PRF算法。
    • PRP
      伪随机置换，与PRF类似，但是PRP生成的结果是一对一的，通常用对称加密算法产生。只用于一些特殊场合。

    参考：
    https://datatracker.ietf.org/doc/rfc2409/
    https://en.wikipedia.org/wiki/Pseudorandom_function_family
    https://thiscute.world/posts/practical-cryptography-basics-4-secure-random-generators/
    NIST SP 800-90A R1,2015年更新
    https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf

    Views: 1

  • 加密算法简介(含国密)

    国际算法

    • DES 旧的对称加密算法，已废弃
    • AES 新的对称加密算法，用于取代DES
    • AES-GCM 加密的同时提供消息验证，密文和验证码(MAC)一起发送,也就是AEAD,其它不带GCM后缀的AES算法不支持AEAD,ipsec和tls1.2,1.3都支持gcm模式
    • Blowfish 对称加密，已废弃
    • chacha20 流式对称加密，使用256位密钥长，对应AES256,安全性与AES相当或略优于AES，纯软件件计算比AES快3倍，比硬件AES慢1倍。这个算法以后用的会越来越多，在没有AES指令集的设备上chacha20是首选算法。由RFC 8439定义。
    • chacha20-poly1305 chacha20的AEAD版
    • RC4 对称加密，特点是速度非常快，比硬件加速的AES还快，已废弃
    • RSA 非对称加密算法，可用于消息加密，消息签名，密钥交换(低于1024位不安全)
    • ECC 非对称加密算法，另外用于密钥交换时用ECDH,用于消息签名时用ECDSA，一般不直接用于加密，根据不同的密钥长度分为P-192, P-224, P-256, P-384 和 P-521。
    • curve25519 非对称加密算法，蒙哥马利曲线,另一种椭圆曲线，256位的密钥长度，比ECC速度更快，更安全
    • curve448 非对称加密算法，448位的密钥长度，curve25519的加强版，安全性更高，但速度没有curve25519快
    • DSA 非对称加密算法，只能用于消息签名，但是用于签名时相比RSA也没有啥优势，所以使用并不多
    • ECDSA DSA的ECC版，ECC一般不直接用于签名，目前基于ECC的数字签名算法就是ECDSA
    • EDDSA 基于爱德华兹曲线的签名算法，速度更快，更安全，用于取代ECDSA，因为NIST有往算法里掺沙子的前科。
    • ED25519 是EDDSA的curve25519实现,密钥长度是256位
    • ED448 是EDDSA的curve448实现，密钥长度448位
    • DH 非对称加密算法，只能用于密钥交换
    • ECDH DH的ECC版,ipsec中DH group 19,20,21使用的是ECDH,其它使用的是DH
    • X25519,X448 ED版的DH算法，分别对应curve25519,curve448，ipsec中对应dh31和dh32
    • DHE,ECDHE 使用临时公私钥的DH，ECDHE算法，提供PFS能力，TLS1.3上PFS是必选的，IPsec可选支持PFS
    • MD5 散列算法，128位，速度很快，已废弃
    • SHA-1 散列算法，160位，已废弃
    • SHA-2(SHA256-SHA512) 散列算法
    • SHA-3(SHA3-256-SHA3-512) 散列算法,长度与sha2一致但使用了不同的算法，是SHA2的备选。目前并没有消息说SHA3比SHA2更安全，只是没有与SHA2相同的弱点。
    • HMAC 加了密码的散列算法，即可以用于散列，也可以用于身份验证(密码不一样，散列结果不一样),HMAC可以与任意其它散列算法一起使用，这样散列算法也实现了AEAD

    国密算法：

    • SM1 相当于AES128，算法不公开，用于小数据量的加解密
    • SM2 基于ECC，相当于ECC256,ECDH,ECDSA,可用于加密，签名，密钥交换，USG6525E防火墙支持使用sm2进行身份认证
    • SM3 相当于SHA-256，但比sha-256g速度慢，支持MAC的版本为HMAC-SM3，USG6525E防火墙不支持IKEV2的完整性验证，但支持sm3用于IKEV1的完整性验证
    • SM4 与SM1一样都是对称加密，用于大数据量的加解密，也可以支持GCM模式(AEAD），USG6525E防火墙中可用于IPsec的数据加密，但不支持GCM模式，所以还需要另外配置完整性验证(使用GCM模式时esp authentication-algorithm不再生效)
    • SM7 与SM1一样，都是128位密钥和分组，主要用于非接触式IC卡,算法不公开
    • SSF33 对称加密，使用较少，算法不公开
    • SM9 非对称加密，使用用户标识(手机号，姓名，email地址)作为公钥，免去了证书创建，使用更方便，属于轻量级的非对称加密
    • ZUC 流式对称加密，可支持AEAD，已成为LTE标准

    注意:
    ECC256的安全性相当于RSA3072
    ECC256的破解难度相当于AES128,对称密码的破解难度要比非对称密码高
    SECP定义的曲线以r1作为后缀的与NIST定义的曲线是相同的，比如secp256r1等于nist p-256,secp38441等于nist p-384，这个定义secp曲线的seca组织是NIST的马甲吗？
    这里可以查看各个曲线的参数定义
    https://neuromancer.sk/std/secg/secp256r1
    secp256k1不是由nist定义的，比特币用的也是这个算法
    brainpool系列曲线是由rfc5639定义的，比nist的更安全，但是速度要慢得多，所以一般用ed25519的多
    爱德华兹曲线相关的ed25519,x25519,ed448,x448是由IETF定义的
    TLS1.3提供了对cure25519,cure448,AEAD的支持，USG6525E支持AEAD但不支持cure25519和cure448
    sha1,sha2,sha3，dsa,ecdsa,aes,ecc NIST P-xxx,des,hmac等算法都是由nist定义的
    关于ipsec中的dh组应该是由ietf自己定义的，可以参考RFC6071，国密算法中没有定义dh组
    各种椭圆曲线算法中只有国密的SM2是能直接加解密数据的,NIST,SECG,IETF定义的ECC和ED25519都不支持加解密数据，而只能用于签名和密钥交换
    2012年起中国国家密码局陆续发布国密算法，2013发生棱境门事件并爆出了Dual_EC_DRBG后门
    中国国家密码局2014年发布GM/T 0022-2014 IPSec VPN技术规范，2023年发布了GM/T 0022-2023 IPSec VPN技术规范
    中国国家密码局发布的商秘(SM)算法不能用于处理国家秘密，只能用于处理商业秘密
    AEAD把认证数据分为加密数据和非加密数据(关联数据)，通过一个MAC保证加密部分和非加密部分均未篡改。通常IP数据包内容是需要加密的数据，IP数据包头是不需要加密的信息。

    Views: 13

  • 华为AR系列路由器使用IPSec实现分支机构之间彼此互通

    路由器在转发包的时候优先顺序依次是NAT，路由表，IPSec策略。
    IPSec报文的处理流程如下(参考:https://forum.huawei.com/enterprise/zh/thread/580935480827068416):

    FW处理流程中，IPSec的处理位于NAT、路由、安全策略之后，故应保证NAT策略对IPSec保护的报文不进行处理，IPSec保护的报文能够通过匹配路由和安全策略被送达应用了IPSec安全策略的接口。具体要求如下：
    1. 到达FW的报文不能匹配NAT Server建立的Server MAP表和反向Server MAP表，否则报文目的地址将被转换。
    2. 到达FW的报文不能匹配目的NAT的策略，否则报文目的地址将被转换。
    3. 路由表中必须有到达IKE对等体私网的路由（一般为缺省路由），路由的出接口为应用了IPSec策略的接口。若没有匹配的路由，报文将被丢弃；若匹配路由的出接口为其它接口，报文也将无法进入IPSec处理模块，以明文形式发送。
    4. IPSec VPN数据流一般在域间流动，故要求开放源域（内网接口所在域）和目的域（应用了IPSec策略的外网接口所在域）之间的域间包过滤，否则报文将被丢弃。
    5. 通过域间包过滤策略检查的报文可以做源NAT，也可以不做。当匹配源NAT的域间NAT策略时，报文源地址被转换，此时匹配security acl的是转换后的源IP地址。当不匹配域间NAT策略时，报文被直接送入IPSec模块。
    6. 进入IPSec模块的报文只有在匹配了security acl的情况下才能被保护，否则被丢弃。

    所以理论上来说只要被路由器接收到并且匹配security acl的报文都会被IPSec转发，接收到的报文可以来自物理接口，也可以是隧道接口或者其它VPN策略接收到的报文。
    因为ipsec使用ACL来匹配要处理的报文，而ACL规则又比较灵活。在ACL中可以同时指定源地址和目的地址，也可以只指定目的地址或源地址，当只指定目的地址时则起到与路由表类似的效果。
    关于security acl有如下描述：

    该命令用于通过ACL方式指定需要IPSec保护的数据流。实际应用中，首先需要通过配置ACL的规则定义数据流范围，再在IPSec安全策略中引用该ACL，才能起到保护该数据流的作用。

    当以IPSec安全策略模板方式创建IPSec安全策略时，定义需要IPSec保护的数据流在协商的响应方为可选：
    •如果协商的响应方不指定需要IPSec保护的数据流，则表示接受发起方定义的需要IPSec保护的数据流的范围。
    •如果协商的响应方指定需要IPSec保护的数据流，则需要与发起方镜像配置或者包含发起方指定的保护的数据流范围。

    也就是说IPSec会结合连接双方的acl配置选取其子集作为生效的报文匹配策略，并不要求双方一致。IPSec连接本身是点对点的。
    基于以上可做如下配置：
    – 在响应方(中心IPSec)配置ACL的目的网段匹配所有分支机构的网段
    – 在请求方(分支机构)配置ACL的目的网段匹配其它分支机构和中心IPSec的网段

    在ACL中仅指定目的网段即可，这样配置等于把对应的目的网段路由到IPSec通道。也可以同时指源网段，但是分支机构多时中心IPSec上的ACL会非常复杂，每个组合都要写才行,所以不建议，也没必要。

    Views: 55