【防火墙技术连载29】强叔侃墙 VPN篇 IPSec引入数字证书,身份认证简单便捷

[复制链接]
发表于 : 2014-7-31 11:24:46 最新回复:2019-03-27 17:38:12
16023 11
强叔侃墙
强叔侃墙 官方号

在前面两篇贴子中,天地会总舵和分舵的网关进行身份认证时都是使用预共享密钥方式。单从配置过程来说,该方式配置简单,只需在总舵和分舵的网关上配置相同的密钥即可。但随着分舵数量越来越多,总舵和每个分舵之间形成的对等体都要配置预共享密钥。如果所有对等体都使用同一个密钥,存在安全风险;而每个对等体都使用不同的密钥,又不便于管理和维护。

分舵数量日益增长,天地会亟需一个新的身份信息认证方案来代替预共享密钥方式,降低管理成本。既然天地会的总舵和分舵都是以合法生意(如当铺和票号)作为掩护,不如直接向官府的刑部申请为当铺和票号发放身份凭证,标明当铺和票号的身份信息。因为刑部是公正的、可信赖的官府部门,所以盖着刑部大印的身份凭证也就是可信任的,总舵和分舵就可以直接通过身份凭证来验证双方的身份。

这个身份凭证就叫做数字证书,简称证书,是由第三方机构颁发的代表设备身份信息的“身份证”。通过引入证书机制,总舵和分舵可以简单便捷地进行身份认证。在详细介绍证书的实现原理和获取方法之前,我们先来了解一下公钥密码学和PKI框架的知识。

公钥密码学公私分明,PKI框架深不可测

Internet危机四伏,IPSec闪亮登场一篇中,我们提到过对称密码学,即总舵和分舵使用相同的密钥来加密和解密。与之对应的是非对称密码学,即加密和解密数据使用不同的密钥,也叫做公钥密码学。目前较常用的公钥密码学算法有RSA(Ron Rivest、Adi Shamirh、LenAdleman)和DSA(Digital Signature Algorithm)。

公钥密码学中使用了两个不同的密钥:一个可对外界公开的密钥称为“公钥”;只有所有者知道的密钥称为“私钥”。这一对密钥的特点是,使用公钥加密的信息只能用相应的私钥解密,反之使用私钥加密的信息也只能用相应的公钥解密。

利用公钥和私钥的这个特点,就可以实现通信双方的身份认证。例如,某个分舵网关使用自己的私钥对信息进行加密(数字签名),而总舵网关使用分舵网关对外公开的公钥进行解密。因为其他人没有该分舵网关的私钥,所以只要总舵使用对应的公钥可以解密信息就确定信息是由该分舵发出来的,从而实现身份认证功能。

了解公钥密码学的基本概念后,如何在实际环境中应用公钥密码学理论呢?PKI(Public Key Infrastructure)正是一个基于公钥密码学理论来实现信息安全服务的基础框架,数字证书是其核心组成部分,而IKE借用了PKI中的证书机制来进行对等体的身份认证。

PKI框架中包括以下两个重要角色:

  • 终端实体(EE,End Entity):证书的最终使用者,例如总舵和分舵的网关。
  • 证书颁发机构(CA,Certificate Authority):是一个权威的、可信任的第三方机构(类似刑部),负责证书颁发、查询以及更新等工作。

通常情况下,终端实体生成公私密钥对,并将公钥、实体信息发送给CA进行证书申请。CA审核实体身份,根据实体的公钥和实体信息制作证书,然后为实体颁发证书。通过这一过程,总舵和分舵网关就可以从CA获取到代表自己身份的证书。

CA生成的证书中包含了大量的信息,我们来看一个常见的证书结构:

 

 

图中各个字段的简要解释如下:

  • 版本:即使用X.509的版本,目前普遍使用的是v3版本(0x2)。
  • 序列号:该序列号在CA服务范围内唯一。
  • 签名算法:CA签名使用的算法。
  • 颁发者:CA的名称。
  • 有效期:包含有效的起、止日期,不在有效期范围的证书为无效证书。
  • 主题:证书所有者的名称。
  • 公钥信息:对外公开的公钥。
  • 扩展信息:通常包含了使用者备用名称、使用者密钥标识符等可选字段。
  • 签名:CA的签名信息,又叫CA的指纹信息。

本篇中所提到的证书分为两种类型:网关自身的证书称为本地证书,代表网关的身份;而CA“自签名”的证书称为CA证书,又叫根证书,代表了CA的身份。

上面简单介绍了证书涉及的几个重要概念,大家先有一个初步了解,关于公钥密码学和PKI框架的详细介绍后续会给出。下面我们来看一下如何为总舵和分舵的网关获取到证书。

证书重要取之有道,在线离线灵活选择

PKI框架中的CA用来处理证书的申请、颁发业务,总舵和分舵的网关可以通过下面两种方式从CA获取证书:

  • 在线方式(带内方式)

网关和CA通过证书申请协议交互报文,在线申请证书,申请到的证书直接保存到网关的存储设备中(Flash或CF卡),常用的证书申请协议有SCEP(Simple Certification Enrollment Protocol)和CMP(Certificate Management Protocol)。该方式适用于网关支持SCEP或CMP的情况,同时依赖于网关与CA之间网络的连通状态。

  • 离线方式(带外方式)

首先,网关生成证书请求文件,我们将该文件通过磁盘、电子邮件等方式将该文件发送给CA。然后,CA根据证书请求文件为网关制作证书,同样通过磁盘、电子邮件等方式将证书返回。最后,我们将证书上传到网关的存储设备中。该方式适用于网关不支持SCEP或CMP的情况,或者网关与CA之间无法通过网络互访的情况。

上述两种方式可根据网关的实际情况灵活选择。下面以离线方式为例,介绍天地会总舵和分舵的网关获取证书的过程。

 

 

离线方式申请证书的流程如下图所示:

 

 

1、创建公私密钥对

首先,在网关FWAFWB上创建各自的公私密钥对,在申请证书时会用到公钥信息。创建过程中,系统会提示输入公钥的位数,位数的长度范围从5122048。公钥的长度越大,其安全性就越高,但计算速度相对来说比较慢。这里我们要求最高的安全性,所以输入2048

在网关FWA上创建公私密钥对:

[FWA] rsa local-key-pair create

The key name will be: FWA_Host

The range of public key size is (512 ~ 2048).

NOTES: If the key modulus is greater than 512,

       It will take a few minutes.

Input the bits in the modulus[default = 512]:2048

Generating keys...

.................................................+++

...............................................+++

..............++++++++

.++++++++

在网关FWB上创建公私密钥对:

[FWA] rsa local-key-pair create

The key name will be: FWB_Host

The range of public key size is (512 ~ 2048).

NOTES: If the key modulus is greater than 512,

       It will take a few minutes.

Input the bits in the modulus[default = 512]:2048

Generating keys...

.................................................+++

...............................................+++

..............++++++++

.++++++++

2、配置实体信息

申请证书时,网关FWAFWB必须向CA提供能够证明自己身份的信息,实体信息代表的就是网关的身份信息,包括:通用名称(Common Name)、FQDNFully Qualified Domain Name)名称、IP地址、电子邮箱地址等。其中,通用名称是必须配置的,而其他几项是可选配置的。

上述信息都将会包含在证书中,在IKE对等体中配置ID类型时,就可以根据证书中包含的实体信息来决定使用哪种ID类型来进行认证。

实体信息配置完成后,还需要在PKI域中引用实体信息。下面给出网关FWAFWB上实体信息和PKI域的配置情况:

关键配置

FWA

FWB

实体信息

pki entity fwa

 common-name fwa   //通用名称

fqdn fwa.tdh.com   //FQDN名称

ip-address 1.1.1.1   //IP地址

email fwa@tdh.com   //Email地址

pki entity fwb

 common-name fwb   //通用名称

fqdn fwb.tdh.com   //FQDN名称

ip-address 3.3.3.3   //IP地址

email fwb@tdh.com   //Email地址

PKI

pki domain fwa

certificate request entity fwa   //PKI域中引用实体信息

pki domain fwb

certificate request entity fwb  //PKI域中引用实体信息

 

3、生成证书请求文件

接下来就可以在网关FWAFWB上生成证书请求文件,生成的证书请求文件以“PKI域名.req”的名字保存在网关FWAFWB的存储设备中,FWA生成的证书请求文件名字是fwa.reqFWA生成的证书请求文件名字是fwb.req

[FWA] pki request-certificate domain fwa pkcs10

Creating certificate request file...

Info: Create certificate request file successfully.

[FWB] pki request-certificate domain fwb pkcs10

Creating certificate request file...

Info: Create certificate request file successfully.

FWA上查看生成的证书请求文件,可以看到里面包含了上面配置的通用名称、FQDN名称、IP地址和电子邮箱地址,以及FWA的公钥信息。

[FWA] display pki cert-req filename fwa.req

Certificate Request:                                                           

    Data:                                                                      

        Version: 0 (0x0)                                                       

        Subject: CN=fwa                                                        

        Subject Public Key Info:                                               

            Public Key Algorithm: rsaEncryption                                

            RSA Public Key: (2048 bit)                                         

                Modulus (2048 bit):                                            

                    00:ae:68:50:18:e7:55:32:7a:0e:61:b6:6e:47:45:              

                    ec:fb:29:d9:1b:4a:9d:6b:b0:00:b0:65:c8:fc:5b:              

                    b4:68:d7:90:7d:96:f7:1d:e4:62:43:06:bc:d0:a3:              

                    5b:b4:fa:30:a3:19:7e:6f:7c:05:6b:47:0c:a2:42:              

                    1b:c4:82:f7:5b:0a:73:a1:0a:8b:00:dd:37:aa:5e:              

                    21:02:56:b2:e6:55:31:08:8f:71:03:13:92:b9:c1:              

                    51:7e:51:04:e2:ca:85:2e:45:97:bb:9a:0e:ed:61:               

                    03:97:d2:1e:44:b2:9f:ff:b9:b1:1d:5d:65:7e:fc:              

                    e6:13:c3:1e:71:81:d0:fe:a0:60:71:a4:8a:40:93:              

                    92:e3:b3:b6:cf:56:f1:30:b2:fc:53:31:bd:9d:6f:              

                    3c:33:1e:4a:a5:6f:83:c7:45:26:8d:c6:9c:84:85:              

                    b5:8f:b9:e3:86:86:59:ad:9b:58:63:a1:3d:7b:81:              

                    d7:43:14:3d:98:4a:a2:cb:82:2c:fa:ca:91:32:b1:              

                    e0:09:de:fa:a8:d6:fc:ea:8e:7e:36:8f:fb:86:31:              

                    1e:bc:5e:01:71:6b:b4:23:86:7b:05:c1:63:7a:f5:              

                    bc:a7:9b:a1:da:ff:4f:26:2d:33:44:06:72:f1:7b:              

                    84:d5:a8:49:1d:be:b4:0e:9c:94:85:34:7b:e5:bb:              

                    8a:49                                                      

                Exponent: 65537 (0x10001)                                      

        Attributes:                                                             

        Requested Extensions:                                                  

            X509v3 Subject Alternative Name:                                   

                IP Address:1.1.1.1, DNS:fwa.tdh.com, email:fwa@tdh.com         

    Signature Algorithm: md5WithRSAEncryption                                  

        4b:a6:fc:91:2a:77:e3:30:02:bb:e4:0f:1a:bf:d2:a1:ad:81:                 

        3e:44:51:81:b1:26:2d:2e:83:7c:0c:29:70:3c:6a:8a:7a:1a:                 

        27:c8:a4:8d:3b:8f:dc:a7:d7:df:10:be:4c:96:1f:f5:db:96:                 

        4d:e9:28:82:b9:2d:9b:e6:6d:22:52:ca:50:07:c2:7a:2b:17:                 

        c7:49:7a:a6:a5:7c:cc:82:02:15:14:ca:9c:69:39:eb:fb:44:                  

        3a:c9:75:d9:f5:b6:bf:b1:45:e4:e7:f4:db:df:eb:3d:6b:74:                 

        ac:14:e9:51:af:b1:c8:d6:c1:19:48:bc:27:c1:37:59:41:38:                 

        9c:1f:9a:7e:c7:fe:20:c9:e8:1d:94:55:ff:85:3e:8c:5a:f5:                  

        f3:ff:9b:18:36:b1:25:2b:4d:60:2e:13:7b:be:91:c0:a1:1f:                 

        6c:5c:1a:f6:3a:5b:e7:87:2b:43:7f:d8:f6:2b:c8:b1:df:7d:                 

        c8:40:df:07:f9:52:4c:8b:ba:b0:10:f3:34:00:00:74:0b:ae:                 

        c1:7a:9c:dd:de:26:26:28:30:de:e8:6c:dc:0a:c6:8f:27:27:                 

        c6:0d:5e:8e:68:a8:8d:cc:eb:91:9c:59:3d:1e:f3:f3:58:72:                 

        16:bf:cc:f5:df:71:bc:51:fb:98:83:c5:2b:17:73:d7:0a:6c:                 

        f7:93:76:f4

4CA根据证书请求文件制作证书

证书请求文件生成后,可以将该文件通过磁盘、电子邮件等方式将该文件发送给CA,由CA为网关FWAFWB制作证书。除了网关FWAFWB的证书之外,CA还会提供自身的证书,即CA证书。CA将制作好的FWAFWB的证书同自身的证书一道通过磁盘、电子邮件等方式返回。

CA制作证书的过程在此不详细介绍,常用的Windows Server操作系统就可以作为CA来申请和颁发证书。

5、导入证书

经过CA的处理,最终我们获取到了网关FWA的证书fwa.cer,网关FWB的证书fwb.cer,以及CA本身的证书ca.cer。下图展示了网关FWA的证书fwa.cer的内容:

 

 

fwa.cerca.cer上传到FWA的存储设备中,将fwb.cerca.cer上传到FWB的存储设备中,然后还需要将证书分别导入到FWAFWB上。

FWA上导入CA证书和本地证书:

[FWA] pki import-certificate ca filename ca.cer

Info: Import file successfully.

[FWA] pki import-certificate local filename fwa.cer

Info: Import file successfully.

FWB上导入CA证书和本地证书:

[FWB] pki import-certificate ca filename ca.cer

Info: Import file successfully.

[FWB] pki import-certificate local filename fwb.cer

Info: Import file successfully.

证书入主对等体,身份认证更便利

导入证书后,网关FWAFWB都是有“身份”的设备了,在IKE对等体中引入证书,FWAFWB就可以通过证书来认证对方的身份。

前面提到过,使用证书进行身份认证时,可以根据证书中包含的实体信息来决定使用哪种ID类型。目前可以在IKE对等体中使用DNDistinguished Name)、FQDNUser-FQDNIP四种ID类型。这四种ID类型对应的证书中字段以及FWAFWB上的取值如下表所示。

ID类型

对应证书中的字段

FWA的取值

FWB的取值

DN

Subject

本端ID/CN=fwa

对端ID/CN=fwb

本端ID/CN=fwb

对端ID/CN=fwa

FQDN

DNS

本端IDfwa.tdh.com

对端IDfwb.tdh.com

本端IDfwb.tdh.com

对端IDfwa.tdh.com

User-FQDN

email

本端IDfwa@tdh.com

对端IDfwb@tdh.com

本端IDfwb@tdh.com

对端IDfwa@tdh.com

IP

IP Address

本端ID1.1.1.1

对端ID3.3.3.3

本端ID3.3.3.3

对端ID1.1.1.1

 

下面以ID类型是DN为例,介绍网关FWAFWB的关键配置:

关键配置

FWA

FWB

IKE安全提议

ike proposal 10

authentication-method rsa-sig   //采用证书认证方式

ike proposal 10

authentication-method rsa-sig   //采用证书认证方式

IKE对等体

ike peer fwb

certificate local-filename fwa.cer    //FWA的证书

ike-proposal 10

local-id-type dn    //ID类型为DN

remote-id /CN=fwb   //FWBDN

remote-address 3.3.3.3   //FWBIP地址

ike peer fwa

certificate local-filename fwb.cer    //FWB的证书

ike-proposal 10

local-id-type dn    //ID类型为DN

remote-id /CN=fwb   //FWADN

remote-address 1.1.1.1   //FWAIP地址

证书属性访问控制策略

pki certificate access-control-policy default permit

pki certificate access-control-policy default permit

 

采用证书方式的IKE协商过程与采用预共享密钥方式的IKE协商过程大致相同,不同之处在于采用证书方式时,两端交互身份信息的ISAKMP消息(主模式是第56ISAKMP消息;野蛮模式是第12ISAKMP消息)中多了证书载荷和签名载荷,具体协商过程不再赘述。

至此,天地会找到了可以代替预共享密钥方式的身份信息认证方案。当新的分舵与总舵建立IPSec连接时,只需要在同一个CA为该分舵申请证书,然后分舵和总舵就可以通过证书来进行身份认证,从而无需再为每个分舵和总舵之间的对等体都维护一个预共享密钥,减少了天地会的管理成本。

说明:数字证书除了在IPSec中使用之外,还可以应用于SSL VPN中客户端和服务器的身份认证,详细内容将会在SSL VPN篇中介绍。

除了新发展的分舵,天地会还有一些老的分舵,已经通过GREL2TP方式接入总舵。如何在不改变原有接入方式的基础上使这些分舵和总舵之间可以安全通信呢?下一篇贴子中将介绍GREL2TP以及移动接入场景中IPSec的相关内容,敬请期待。

 

 

上一篇 VPN篇 IPSec遭遇NAT处变不惊,见招拆招化险为夷

下一篇 VPN篇 IPSec兼容并济吸纳百家,GRE和L2TP改头换面深藏不漏

汇总贴

本帖被以下专题推荐:

  • x
  • 常规:

点评 回复

跳转到指定楼层
DoubleDong
DoubleDong   发表于 2014-9-14 15:45:29 已赞(0) 赞(0)

看完了  标记一下!

  • x
  • 常规:

点评 回复

Sophoni
Sophoni  版主 发表于 2014-7-31 11:41:00 已赞(0) 赞(0)

欢迎学习!!

  • x
  • 常规:

点评 回复

shadowboy
shadowboy   发表于 2014-7-31 15:10:38 已赞(0) 赞(0)

图片,,有挂了。。。。老挂

  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2014-7-31 15:13:39 已赞(0) 赞(0)

回复 3 楼

多谢,重新编辑了一下,现在再看看

  • x
  • 常规:

点评 回复

shadowboy
shadowboy   发表于 2014-7-31 16:02:52 已赞(0) 赞(0)

引用 4 楼

多谢,重新编辑了一下,现在再看看

强叔侃墙 发表于 2014-07-31 15:13

 

好了。。图片,老爱挂。。。。

  • x
  • 常规:

点评 回复

wangbenlie
wangbenlie   发表于 2014-7-31 17:50:51 已赞(0) 赞(0)

感谢分享!
  • x
  • 常规:

点评 回复

周中斌
周中斌   发表于 2014-9-23 17:09:46 已赞(0) 赞(0)

申请证书时,除了网关的证书外,多出来一个CA的证书,CA证书的作用是什么?必须要导入设备的吗?

  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2014-9-23 18:55:43 已赞(0) 赞(0)

回复 8 楼

这个CA证书是用来验证对方发过来的证书的,比如客户端与SSL VPN网关使用证书方式认证,那么客户端就会把自己的证书发给网关,网关用事先导入的CA证书来验证客户端证书的真伪。
  • x
  • 常规:

点评 回复

parhelia
parhelia   发表于 2015-3-4 12:49:28 已赞(0) 赞(0)

回复 9 楼

您好,咨询几个问题(ike v1)

1.证书认证中,在主模式3、4交互后的skeyid是如何计算出来的?psk方式相对简单,只要查询到对应psk再参与skeyid计算即可,证书方式呢,是设备证书(local)的公钥或是私钥还是说是对应CA证书的公钥,因为最后peer之间计算出的对称密钥必须相同,要保证相同的话就个人觉得就必须是采用CA的公钥参与计算才有可能相同,并且设备证书必须是向同一个CA申请的才行?个人对此一直不解

2.我看过相关华赛时期的资料,介绍ipsec时强调主模式下不支持认证ID类型为字符串方式(name),仅支持IP,原理是3、4报文交互后需要查找对应的psk,而name相关信息携带在5、6报文中,不会通过remote-address查找对应的psk,因此该场景仅支持野蛮模式,同时要求nat穿越场景需要野蛮模式+认证ID类型name(fqdn),希望确认的是否现在版本(V3R1之后)查找psk都以remote-address为准?主模式也可支持fqdn方式。同时,过去资料强调主模式psk认证方式场景下不支持nat穿越,应该是之前没得策略模板方式和remote-address authentication-address XXX这条命令,看您的案例配置再结合我处理过的一些l2tp over ipsec 故障问题,个人觉得应该是如此,请强叔帮忙确认一下

3.最后一个问题是当采用策略模板方式不指定对端IP(等同于any)时,是否不再验证对端ID(没有指定、无法验证),只要psk两端相同、能解密对端发送(5、6)加密载荷即可?

 

 

  • x
  • 常规:

点评 回复

12
返回列表
发表回复
您需要登录后才可以回帖 登录 | 注册

警告 内容安全提示:尊敬的用户您好,为了保障您、社区及第三方的合法权益,请勿发布可能给各方带来法律风险的内容,包括但不限于政治敏感内容,涉黄赌毒内容,泄露、侵犯他人商业秘密的内容,侵犯他人商标、版本、专利等知识产权的内容,侵犯个人隐私的内容等。也请勿向他人共享您的账号及密码,通过您的账号执行的所有操作,将视同您本人的行为,由您本人承担操作后果。详情请参看“隐私声明
如果附件按钮无法使用,请将Adobe Flash Player 更新到最新版本!
登录参与交流分享

登录参与交流分享

登录