CN113647079B - 用于为用户签发加密保护的真实性证书的方法 - Google Patents

Abstract

本发明涉及一种为用户(B1，B2，B3)签发加密保护的真实性证书(CERT)的方法，该方法具有以下步骤：‑提供公共用户密钥，‑为与用户相关联的客户端提供公共客户端密钥，‑形成请求(CSR)，该请求包含公共用户密钥，并且借助与所提供的公共客户端密钥相关联的私人客户端密钥进行保护和/或数字签名，并且‑签发加密保护的真实性证书，该真实性证书包含公共用户密钥并且对客户端进行识别。优选地，加密保护的真实性证书包含或引用加密的客户端标识符(M‑ID)，该客户端标识符依据公共客户端密钥形成。

Description

用于为用户签发加密保护的真实性证书的方法

技术领域

本发明涉及一种用于为用户签发加密保护的真实性证书的方法，例如为用户签发数字证书、特别是设备证书的方法，并且还涉及相关的装置。

背景技术

在本说明书的范围中，术语“安全”或“安全性”主要是指数据以及其传输的安全性或保护性、保密性和/或完整性以及在访问相应数据时的安全性、保密性和/或完整性。如在本说明书的范围中所使用的，术语“安全性”还包括在数据传输或数据访问时的认证。在此，模块在这里可以形成为硬件单元和/或功能单元，功能单元可以以软件和/或固件形式形成。例如，功能可以借助处理器和/或用于存储程序命令的存储单元来执行。

在基于证书的系统中，每个人或每个对象、例如设备或软件程序都会获得真实性证书，例如数字证书，数据结构(或数据组)，其包含与人或对象的身份有关的说明以及人或用户或对象或设备的公共密钥。每个证书由签发机构通过数字签名进行认证，在数字签名方面，其可以由更高的机构再次认证。由于数字签名包括完整的数据结构，其内容因此得到了完整性保护。这种私人密钥架构(Private Key Infrastructure，PKI)的信任系统是分层级的。所谓的根证书(也被称为Root Certificate)形成了共同的信任锚，在所有相关的系统部件中必须真实地配置根证书。

数字证书的真实性和完整性也通过数字签名来检查。为此，借助秘密的签名密钥(也被称为私人密钥)针对数据组计算出一个值，该值被称为数字签名。这个值可以实现，任何人都可以借助相关的公共验证密钥(也被称为公共密钥)来检查数据组的不可否认的作者身份和完整性。为了能够将利用签名密钥创建的签名与用户相关联，必须明确地将相关的验证密钥与这个用户相关联。

在下文中，认证机构通常也被称为用于颁发证书的装置或证书颁发装置。

在物理上特别保护的安全模块，例如加密处理器、硬件安全模块(hardwaresecurity module，HSM)或可信平台模块(trusted platform module，TPM)中存储秘密的对称的和私人的非对称的密钥同样也是可能的。安全模块也可以以软件/固件的方式实现。秘密或私人密钥可以被录入安全模块或在其中生成。从安全模块读取密钥通常是不可能的，或者只在非常有限的范围内可能。

可以为属于用户的每个设备生成新的、非对称的密钥对。私人密钥必须保留在设备中，并且进行可靠的保护，以防止未经授权的使用，以及特别是防止读取和复制；以真实的方式将公共密钥传输到认证机构(Certification Authority)，简称CA，其被配置为颁发装置，其将公共密钥与其他设备数据(序列号、类型、制造商名称、生产日期等)一起在数据结构中进行数字签名。为了确保公共密钥和相关的设备数据的所有者也拥有相对应的私人密钥，由设备产生的数据组也经常利用设备或用户的相应私人密钥进行数字签名，以保护从设备到CA的传输。该设备可以是物联网(IOT)设备或例如具有安全模块的其他设备。

通常，需要数字证书来进行对用户的认证，特别是进行对工业自动化系统/控制系统的设备或部件的认证。

如上所述，数字证书通常是由公共密钥架构(Public Key Infrastruktur，PKI)签发的。然而，安全的PKI的结构和运作是相对复杂的。技术性的PKI机构有可能被多个客户端共同使用。尽管技术性的PKI架构由多个客户端共同使用，但从逻辑角度看，好像客户端分别使用其自己的PKI架构。客户端例如可以是自动化系统的不同的运营商、不同的自动化企业或不同的公司或业务部门，他们分别需要一个PKI架构。在此，与客户端相关联的用户可以是设备制造商的服务人员，也可以是自动化/控制系统运营商的服务人员。在此，用户承担不同的角色，以这种方式，他们获得对用户或系统的设备和/或部件的访问权，以完成例如对客户端的特定配置工作或维护工作。通过这些角色，用户被授权在用户或系统的设备上完成特定任务。

然而，在PKI架构中安全地设置和维护客户端的成本很高。在此，客户端通常是针对运营商封闭的PKI区域，该PKI区域不与其他运营商共享。

发明内容

本发明要解决的技术问题是，相对于上面提到的现有技术改进方法和装置或系统或设备。

上述技术问题通过独立权利要求中给出的特征来解决。在从属权利要求中给出本发明的有利的扩展。

本发明要求保护一种为用户签发加密保护的真实性证书的方法，其具有以下步骤：

-提供(用户的)公共用户密钥，

-为与用户相关联的客户端提供公共客户端密钥，

-形成用于签发加密保护的真实性证书的请求，

其中，该请求包含公共用户密钥，并且借助与所提供的公共客户端密钥相关联的私人客户端密钥进行保护和/或数字签名，并且

-签发加密保护的真实性证书，其包含公共用户密钥并且识别客户端。

通过确认或正在确认或肯定地检查该请求与客户端的隶属关系来识别客户端。

在此，所提供的真实性证书包含公共用户密钥，如同一般情况那样。然而附加地，其还包含用于识别或标记如下客户端的信息元素，该客户端借助其私人客户端密钥对请求进行保护和/或数字签名。

本发明的优点在于，不需要在PKI架构中明确地设置客户端。客户端是由公共客户端密钥隐含提供的，可以用其来检查证书请求。因此，客户端可以完全自动地并且必要时针对每个证书请求“即时(on the fly)”设置。尽管如此，其确保了，可以可靠地将第一客户端的真实性证书与第二客户端真实性证书区分。

客户端可以存储更多的公共密钥(public Keys)，这些公共密钥与公共客户端密钥相关联。然后，该客户端的证书请求也可以利用分别与公共密钥相关联的另外的私人密钥来保护。

优选地，对于识别用户的真实性证书的认证请求包含或引用加密的客户端标识符，其依据公共客户端密钥形成。然而，也有可能为认证请求自动添加加密的客户端标识符。

因此，“请求者”、即相应的客户端确认/授权：证书的签发是允许的。

该请求可以包含取决于公共客户端密钥的客户端标识符。客户端标识符可以由公共客户端密钥的哈希值形成。

用于为用户签发加密保护的真实性证书的请求还可以在对客户端进行认证之后形成和/或进行传输，其中该请求可以通过通信连接(例如TLS/IPsec/IKE)进行传输，该通信连接借助客户端标志或借助所形成的客户端标识符来认证。

在形成和转发请求的机构、例如注册机构(RA)中，可以进行对请求的认证并且可以基于此进行授权。最终，该认证是一种“证书签发授权标识符”。由此，用户或形成并转发请求的机构(RA)确认证书签发的可允许性。

本发明的另外的方面是一种装置、特别是认证机构(CA)，其用于借助所提供的公共用户密钥为用户签发加密保护的真实性证书，其具有：

-确认单元，其被配置为用于签发加密保护的真实性证书，其包含公共用户密钥并识别客户端，其中确认单元确认(或检查)之前的真实性证书请求与客户端的隶属关系和/或可允许性。

本发明的另外的方面是一种装置、特别是注册机构(RA)，其用于为用户签发加密保护的真实性证书，其具有：

-提供单元，其被配置为用于为与用户相关联的客户端提供公共客户端密钥，

和

-生成单元，其被配置为用于形成用于签发加密保护的真实性证书的请求，其中该请求可以借助与所提供的公共客户端密钥相关联的私人客户端密钥进行保护和/或数字签名，该请求包含用户的公共用户密钥或利用其进行数字签名。

此外，还规定了一种包括程序代码的计算机程序(产品)，该程序代码可以由至少一个处理器执行，并且使至少一个处理器执行根据本发明的(运行)方法及其实施方式。该计算机程序可以在上述类型的装置上运行，或者作为计算机程序产品存储在计算机可读介质上。

装置、系统或设备、模块和计算机程序(产品)可以根据所述方法的扩展/实施方式以及它们的扩展/实施方式进行设计，反之亦然。

附图说明

结合下面对结合附图详细阐述的实施例的描述更清楚且明晰地理解上面描述的本发明的特点、特征和优点以及其实现方式。在此，以示意性的方式：

图1示出了用于请求或颁发真实性证书或证书的实施例；

图2示出了证书请求消息的实施例；和

图3示出了所请求的证书的实施例。

具体实施方式

根据本发明，图1示出了用于请求或颁发真实性证书或证书的过程。

三个不同的运营商B1、B2、B3或用户使用本地注册机构(RegistrationAuthority，RA)RA1、RA2、RA3，以便授权证书请求。所有三个运营商分别使用自己的证书签发者CA1、CA2、CA3，其以特定于运营商的方式签发证书。这三个运营商也可以使用唯一一个证书签发者CA(用虚线表示)。为此，每个注册机构具有与签发者、例如CA的已认证的通信连接，签发者可以基于用于认证的私人客户端密钥来签发证书。在该示例中，与客户端相关联的用户承担不同的角色，例如他们获得对用户例如B1或系统的设备D1和D2或部件的访问，以便例如完成特定的配置工作或维护工作。通过这些角色，用户被授权在用户或客户端的系统的设备上完成特定任务。

客户端密钥对(公共密钥、私人密钥)的公共密钥KPUP被用来识别客户端。由此，加密的客户端标识码或客户端标识符M-ID可以依据所使用的客户端密钥对自动确定(例如，确定为公共客户端密钥的哈希值H)。

对数字证书CERT的要求或请求(证书签名请求，Certificate Signing Request)CSR受到客户端密钥的保护，其在图1中通过方括号表示。特别地，证书请求可以通过与公共客户端密钥相关联的私人客户端密钥进行数字签名，这用Sig来标记。证书请求CSR也可以通过通信连接(例如TLS、IPsec/IKE)来传输，该通信连接借助私人客户端密钥进行认证。

通过私人客户端密钥进行的保护可以由提出请求的客户端节点(请求者或要求者)本身进行或由中间节点、特别是由注册机构RA进行，注册机构在检查消息内容之后，将证书请求消息转发到证书签发者CA。加密的客户端标识码或客户端标识符包含在为该客户端申请的、已签发的证书中，或在其中被引用。加密的客户端标识符可以包含在所签发的证书的名称CN(参见图2)中和/或客户端子CA证书的名称中。因此，客户端只能请求也是实际上与其(即，其加密的客户端标识符)相关联的证书。在此，可以检查证书请求是否包含适当的加密的客户端标识符。只有在是这种情况时，证书才由证书签发者CA签发，即证书请求消息由证书签发者CA进行数字签名，或者相应于证书请求消息CSR形成的证书CERT由证书签发者CA进行数字签名。如图2中所示，证书请求消息也可以通过输入适当的加密的客户端标识符来修改。

总而言之，以下的实施方式是可能的：

-证书请求消息可以利用私人客户端密钥进行数字签名。签名可以利用公共客户端密钥进行检查。签名可以通过提出请求的客户端、证书管理代理或注册机构RA进行。

-证书请求消息可以被数字签名两次，一次利用提出请求的客户端或用户的私人密钥(即，利用要通过证书确认与其关联的公共密钥PK的私人密钥)，另一次利用私人客户端密钥。对于数字签名，例如可以使用根据CMP协议(Certificate Management Protocol，证书管理协议，IETF标准RFC 4210)的证书请求的重新签名。

-在使用已认证的通信连接以传输证书请求的情况下，例如可以使用EST(Enrollment over Secure Transport，基于安全传输的注册，IETF标准RFC 7030)。在此，建立与注册机构RA的TLS连接(Transport Layer Security，传输层安全，IETF标准RFC5246)，注册机构检查并授权请求者的认证请求。从RA到进行签发的CA建立另外的TLS连接，其中使用私人客户端密钥和相关客户端的证书以进行认证。包含公共客户端密钥的证书例如可以设置密钥使用扩展id-kp-cmcRA。

客户端可以存储另外的公共密钥，这些另外的公共密钥与公共客户端密钥相关联。然后，该客户端的证书请求也可以利用相关联的另外的公共密钥进行保护。这种应用是灵活的。

例如，只有在请求消息已经包含了对应于客户端标识符的字段时，才可以通过CA签发证书(即，对与CSR的内容相对应的数据结构进行签名)。替换地，CA也可以从公共客户端密钥(证书)中确定该信息。

原则上，可以将加密的客户端标识符编码或插入到证书的任何属性中，例如通用名称(Common Name)CN(如图3所示)、组织单位(Organizational Unit，OU)或AltName。如果签发的证书受到子CA证书(Sub)CA-CERT(参见图3所示的虚线)的保护，(Sub)CA-CERT包含加密的客户端标识符M-ID，则其也可以被隐含地包含(引用)。

优选地，证书中的名称的形成不仅取决于客户端密钥的公共密钥，而且还取决于要确认的设备D1、D2的公共密钥PK(Device Key，设备密钥)。

形成客户端标识符的例子：

串联部分KPUP|PK

HMAC(KPUP,PK)，其中HMAC表示密钥哈希消息认证码(Key-Hashed MessageAuthentification Code)。

优选地，对CSR进行两次签名：

-公共客户端密钥(KPUP，Mandanten Public Key)

-设备公共密钥(PK，Device Public Key)

优选地，包含证书扩展(Certificate Extension)，其引用该特定类型的证书签发(通过CA规范扩展(eine CA Policy Extension)或单独的证书扩展)。

下面的例子示出了这种扩展。

在证书中，该扩展应该被标记为“关键”，因为由此在验证过程中，该扩展也总是被共同处理。由此确保了不仅要检查证书签发者的签名，而且还要检查是以谁的名义创建的证书。通过验证者方面的相应的安全规范(Security Policy)，验证者因此能够仅仅使用已经为特定客户端签发的证书。

参数MandantID(客户端ID)尤其可以是公共客户端密钥的哈希值(例如SHA256，SHA3)。客户端标识符MandantID可以以二进制进行编码或编码为字符串(例如，作为十六进制值的ASCII字符串)。

证书验证或证书检查可以按以下方式进行：

-确定加密的MandantID(白名单)，其例如被明确地配置或隐含地来自自己的证书，“请求者(对等节点，peer node)是否与检查的节点属于同一个客户端，或者该客户端是否已知并且被接受？”

-如果是，则接受该证书。

可选地，带有加密名称部分的DNS名称也附加地可以相应于证书来形成(例如针对在node.js情况下的自发的网络服务：一个节点可以自发地为一个网络服务建立HTTPS服务，即形成一个适合所签发的证书的网络名称)。

虽然在细节上通过优选的实施例对本发明进行了详细的阐述和描述，但是本发明却不限于所公开的示例并且本领域技术人员可以从中导出其它变形方案，而不脱离本发明的保护范围。

前面描述的过程或方法流程的实现可以根据指令进行，这些指令存在于计算机可读存储介质或易失性计算机存储器中(下面统称为计算机可读存储器)。计算机可读存储器例如是易失性存储器，如缓存、缓冲器或RAM，以及非易失性存储器，如可移动存储器、硬盘等。

在此，前面描述的功能或步骤可以以至少一个指令组的形式存在于计算机可读存储器中/上。在此，这些功能或步骤不受特定的指令组或特定形式的指令组或特定的存储介质或特定的处理器或特定的实施模式的约束，并且可以由软件、固件、微代码、硬件、处理器、集成电路等以单独运行或任意组合的方式执行。在此，可以使用极其不同的处理策略，例如由单个处理器进行串行处理或多处理或多任务或并行处理等。

指令可以存储在本地存储器中，但是也可以将指令存储在远程系统中并通过网络进行访问。

该设备或装置分别可以具有一个或多个处理器。术语“处理器”、“中央信号处理”、“控制单元”或“数据评估装置”包括最广泛意义上的处理装置，例如服务器、通用处理器、图形处理器、数字信号处理器、特定于应用的集成电路(ASIC)、可编程逻辑电路(如FPGA)、离散的模拟或数字电路及它们的任意组合，包括本领域技术人员已知或未来开发的所有其他处理装置。在此，处理器可以包括一个或多个装置或系统或单元。如果处理器由多个装置组成，它们可以被设计或配置为并行或顺序处理或执行指令。

Claims (9)

1.一种为用户(B1，B2，B3)签发加密保护的真实性证书(CERT)的方法，所述方法具有以下步骤：

-提供公共用户密钥，

-为与用户相关联的客户端提供公共客户端密钥，其中以通过公共客户端密钥检查证书请求的方式来完全自动地设计客户端，

-形成请求(CSR)，所述请求包含取决于所述公共客户端密钥的、加密的客户端标识符(M-ID)以及公共用户密钥，并且借助与所提供的公共客户端密钥相关联的私人客户端密钥进行保护和/或数字签名，并且

-签发加密保护的真实性证书，所述加密保护的真实性证书包含公共用户密钥以及用于识别或标记如下客户端的信息元素，所述客户端已经借助其私人客户端密钥对所述请求进行了保护和/或数字签名，并且由此对客户端进行识别，

其中，所述加密保护的真实性证书包含或引用所述加密的客户端标识符(M-ID)，所述客户端标识符依据公共客户端密钥由所述公共客户端密钥的哈希值形成。

2.根据权利要求1所述的方法，其特征在于，用于签发加密保护的真实性证书的请求在对用户进行认证之后形成和/或进行传输。

3.根据权利要求1或2所述的方法，其特征在于，所述请求通过通信连接进行传输，所述通信连接借助客户端标志或借助所形成的客户端标识符来认证。

4.根据权利要求1或2所述的方法，其特征在于，执行证书验证，所述证书验证包括：

-确定加密的客户端标识符(M-ID)，所述加密的客户端标识符明确地或隐含地根据自己的证书进行配置，

-如果请求者与检查的节点属于同一个客户端，或者所述客户端是已知的以及被接受的，则接受所述证书。

5.一种用于借助提供的公共用户密钥为用户签发加密保护的真实性证书的装置(CA)，所述装置具有：

-确认单元，所述确认单元被配置为用于签发加密保护的真实性证书，所述真实性证书包含公共用户密钥并且对客户端进行识别，其中所述确认单元确认之前的真实性证书请求与客户端的隶属关系，并且其中以通过公共客户端密钥检查证书请求的方式来完全自动地设计客户端，其中，对客户端进行识别的真实性证书包含或引用加密的客户端标识符，所述客户端标识符能够依据客户端密钥形成。

6.一种用于为用户签发加密保护的真实性证书的装置(RA)，所述装置具有：

-提供单元，所述提供单元被配置为用于为与用户相关联的客户端提供公共客户端密钥，

和

-生成单元，所述生成单元被配置为用于形成用于签发加密保护的真实性证书的请求，其中所述请求借助与所提供的公共客户端密钥相关联的私人客户端密钥进行保护和/或数字签名，所述请求包含用户的公共用户密钥，并且其中，所述请求包含取决于所述公共客户端密钥的客户端标识符，所述客户端标识符能够由所述公共客户端密钥的哈希值形成，其中所述客户端只能请求与其加密的客户端标识符相关联的证书。

7.根据权利要求6所述的装置，其特征在于，用于签发加密保护的真实性证书的请求能够在对用户进行认证之后形成和/或进行传输。

8.根据权利要求6或7所述的装置，其特征在于，所述请求能够通过通信连接进行传输，所述通信连接借助客户端标志或借助所形成的客户端标识符来认证。

9.一种计算机可读介质，在其上存储有计算机程序产品，所述计算机程序产品能够直接加载到一个或多个数字处理器的存储器中，所述计算机程序产品包括程序代码部分，所述程序代码部分适合于执行根据上述方法权利要求中任一项所述的方法的步骤。