42

uCPE的零接触配置–第2部分

 4 years ago
source link: https://www.sdnlab.com/23662.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

该系列文的第一部分《uCPE的零接触配置–第1部分》介绍了公共网络上uCPE ZTP的安全问题,并且还讨论了uCPE与不同网络ZTP实体之间的身份验证问题。身份验证(例如,密码或 PSK)在某种程度上与零接触的一般概念相矛盾。第2部分将重点介绍安全证书及其在ZTP中的使用。

10uCPE_part668.jpg

在讨论安全证书之前,我们需要了解非对称密钥加密(也称为公钥加密)的概念,它是安全证书的核心加密方法。

非对称密钥加密

如第1部分所述,对称密钥加密是基于使用完全相同的密钥Ks对消息进行加密和解密。为了方便起见,我们将在此处标记加密和解密操作ƒ(Ks,x)和ƒ-1(Ks,x)(其中x是函数输入),使用相同的密钥。因此,对某个消息m的加密和解密过程,将由:ƒ1(Ks,f(Ks,m)≡表示。

在非对称密钥加密中,会生成两个相关的[1]密钥:私钥KPr和公钥KPu。私钥可以属于特定的人或实体(例如uCPE),并安全地保存在该实体中。而公钥可以分发给每个人。

为了将加密消息发送给某人(或某个设备),需要将其已知的公钥与加密函数e(Kpu,x)结合使用来生成加密消息。加密消息的接收者需要将其私钥与解密函数d(Kpr,x)一起使用以检索原始消息:d(Kpr,e(Kpu,m))≡m。由于只有合法的地址才具有与加密邮件的公用密钥相匹配的私钥,因此只有该地址才能够成功解密原始邮件。

使用非对称密钥对消息进行数字签名以允许对消息的来源进行身份验证也非常简单。为了对用户消息(或文档)进行签名,用户所需要做的就是将私钥(只有该用户知道)与签名功能一起使用,并生成一个数字签名s(Kpr,m)。通过将验证函数和已知公钥一起应用于消息签名,此签名消息(消息+签名)的接收者将能够验证消息确实来自目标用户(即,验证目标用户的签名):v(Kpu, s(Kpr,m))≡1。

10uCPE_part01.jpg

使用非对称密钥加密的数字签名

如图所示,通过使用非对称密钥加密,无需在通信建立之前预先为端点加密。只要端点具有{Pr,Pu}密钥对,所有的加密操作都可以在不交换单个密钥的情况下进行。

最广为人知的公钥算法是1978年由Rivest-Shamir-Adleman发明的RSA。此后,又出现了其他非对称加密算法,例如1985年Neal Koblitz和Victor S. Miller独立提出的椭圆曲线密码算法(ECC)。然而,RSA仍然是当今最普遍的数字签名算法。

看到这边,您可能已经在问自己:“究竟是谁为特定实体(个人或机器)准确地提供了密钥对呢?”此外,一旦某个“密钥管理实体”向我提供了密钥对,我如何向全世界证明我是该密钥对的合法所有者?确实,由于公共密钥加密技术是基于:每个实体都具有一个加密私有密钥以及“众所周知”的公共密钥,因此管理这些密钥的问题变得非常重要。

安全证书和PKI

安全证书(由ITU-T X.509定义)是一种数字文档(基本上是一个文件),该文档将特定实体(证书中的“使用者名称”字段)与公共密钥(证书中的“使用者公共密钥”字段)绑定在一起。因此,通过使用这样的证书,人们可以向世界证明它们被分配了特定的公共密钥。证书由证书管理实体(称为证书颁发机构(CA)的)分配,证书管理实体还使用自己的私钥将其数字签名应用于证书。此证书管理和分发机制称为公钥基础结构(PKI)。PKI是用于创建,存储和分发数字证书的系统,这些证书用于验证特定的公共密钥是否属于某个实体。PKI创建将公共密钥映射到实体的数字证书,将这些证书安全地存储在中央,并在需要时将其吊销。

10uCPE_part02.jpg

PKI架构

CA可以是一个受信任的全球实体(例如Symantec Corp),它向银行、公司、教育机构、网站等组织有偿分配证书。CA也可以具有更多的本地性质,隶属于一个组织(同样是商业、教育或政府组织),仅向该组织的内部基础设施提供有限范围的证书。

无论范围是什么,CA始终拥有自己的X.509证书(将自己的名称与公共密钥绑定),以及匹配的私有密钥,该私有密钥被安全地存储并且永远不会公开。CA将使用此私钥为其他实体签署证书。CA证书一般是“自签名的”,并为实体(实体的证书已由CA签名)提供信任的PKI根(允许一个CA证书由另一个CA签名。因此,可以形成CA的层次结构,有时称为“信任链”。但是,层次结构中的最高ca总是自签名的。)。

10uCPE_part03.jpg

使用PKI进行验证的方式如下:每当一个实体被要求证明其身份时,它首先将自己的证书发送给验证对等方。验证对等方会检查实体的证书,并且(在确保其格式正确之后)查看使用哪个CA对证书进行签名(此信息也是证书的一部分)。假设验证对等方可以访问自签名CA证书(当然,假设验证对等方信任该CA),则他们能够使用该CA的公钥(属于CA证书的一部分),以验证实体证书的真实性。一旦发生这种情况,验证对等方就可以使用证书中的公钥来验证实体本身的真实性。这形成了一个信任链,从受信任的CA开始,直到实体证明其身份为止。

简而言之,使用PKI进行实体真实性验证的步骤包括:第一,使用CA颁发的证书验证其证书的真实性,第二,一旦我们知道该实体的证书是有效的,使用它自己的证书验证该实体本身。从这种意义上讲,基于PKI的身份验证同时使用了我只知道的东西(私钥)和我拥有的东西(签名证书)。

证书的使用极大地简化了身份验证过程,因为它不要求在ZTP之前在设备中提供临时密码或PSK。但是,为了工作,必须在早期生产或分阶段过程中将证书(设备和签名CA两者)注册到设备中。一旦您将证书注册到设备中,以后就可以用它们来打开设备的所有安全连接。当然,如果需要更高的安全性,可以将许多设备证书(每个证书与不同的私钥相关联)注册到特定的设备(例如,一个证书用于打开SSL / TLS连接,另一个证书用于IPsec)。

在实践中,通过将设备连接到网络中的某个CA服务器来实现对设备的证书注册。设备通常会生成一个非对称密钥对,并使用它的公钥向CA服务器生成证书签名请求(CSR)。CA服务器将接收CSR,在验证其格式和详细信息之后,将对其进行签名,并将签名后的证书返回给设备。这个过程可以通过向CA服务器导入/导出文件来手动执行,也可以通过更自动化的证书注册协议(如简单证书登记协议(SCEP))来执行。

既然已经讨论了安全问题,我们需要确保uCPE操作系统和任何软件一样,在ZTP过程中得到正确的许可,以便在ZTP完成后能够实现其全部功能。

原文链接:
https://www.rad.com/blog/zero-touch-provisioning-ucpe-part-2


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK