对称密钥证明Symmetric key attestation

本文介绍了在使用含设备预配服务的对称密钥时的标识证明过程。This article describes the identity attestation process when using symmetric keys with the Device Provisioning Service.

对称密钥证明是一种通过设备预配服务实例对设备进行身份验证的简单方法。Symmetric key attestation is a simple approach to authenticating a device with a Device Provisioning Service instance. 此证明方法表示不熟悉设备预配或不具备严格安全要求的开发人员的“Hello world”体验。This attestation method represents a "Hello world" experience for developers who are new to device provisioning, or do not have strict security requirements. 使用 TPMX.509 证书的设备证明更加安全,且应用于更严格的安全要求。Device attestation using a TPM or an X.509 certificate is more secure, and should be used for more stringent security requirements.

对称密钥注册还为具有有限安全功能的旧设备提供了通过 Azure IoT 启动到云的绝佳方法。Symmetric key enrollments also provide a great way for legacy devices, with limited security functionality, to bootstrap to the cloud via Azure IoT. 有关旧设备的对称密钥证明的详细信息,请参阅如何为旧设备使用对称密钥For more information on symmetric key attestation with legacy devices, see How to use symmetric keys with legacy devices.

对称密钥创建Symmetric key creation

默认情况下,当保存新注册且启用“自动生成密钥”选项时,设备预配服务会创建默认长度为 32 个字节的新对称密钥 。By default, the Device Provisioning Service creates new symmetric keys with a default length of 32 bytes when new enrollments are saved with the Auto-generate keys option enabled.

自动生成对称密钥

还可以通过禁用此选项来为注册提供你自己的对称密钥。You can also provide your own symmetric keys for enrollments by disabling this option. 在指定你自己的对称密钥时,你的密钥长度必须介于 16 个字节与 64 个字节之间。When specifying your own symmetric keys, your keys must have a key length between 16 bytes and 64 bytes. 此外,对称密钥必须以有效的 Base64 格式提供。Also, symmetric keys must be provided in valid Base64 format.

详细证明过程Detailed attestation process

使用 IoT 中心支持的相同安全令牌来执行含设备预配服务的对称密钥证明,以标识设备。Symmetric key attestation with the Device Provisioning Service is performed using the same Security tokens supported by IoT hubs to identify devices. 这些安全令牌都是共享访问签名 (SAS) 令牌These security tokens are Shared Access Signature (SAS) tokens.

SAS 令牌具有使用对称密钥创建的哈希签名 。SAS tokens have a hashed signature that is created using the symmetric key. 设备预配服务会重新创建该签名,以验证在证明期间显示的安全令牌是否可信。The signature is recreated by the Device Provisioning Service to verify whether a security token presented during attestation is authentic or not.

SAS 令牌的格式如下:SAS tokens have the following form:

SharedAccessSignature sig={signature}&se={expiry}&skn={policyName}&sr={URL-encoded-resourceURI}

下面是每个令牌的组成元素:Here are the components of each token:

Value 说明Description
{signature}{signature} HMAC-SHA256 签名字符串。An HMAC-SHA256 signature string. 对于单个注册,此签名通过使用对称密钥(主密钥或辅助密钥)执行哈希而生成。For individual enrollments, this signature is produced by using the symmetric key (primary or secondary) to perform the hash. 对于注册组,从注册组密钥中派生的密钥用于执行哈希。For enrollment groups, a key derived from the enrollment group key is used to perform the hash. 哈希在以下格式的消息上执行:URL-encoded-resourceURI + "\n" + expiryThe hash is performed on a message of the form: URL-encoded-resourceURI + "\n" + expiry. 重要说明:必须先从 base64 解码密钥,然后才能将其用于执行 HMAC-SHA256 计算。Important: The key must be decoded from base64 before being used to perform the HMAC-SHA256 computation. 此外,签名结果必须为 URL 编码。Also, the signature result must be URL-encoded.
{resourceURI}{resourceURI} 以设备预配服务实例的范围 ID 开头、可通过此令牌访问的注册终结点的 URI。URI of the registration endpoint that can be accessed with this token, starting with scope ID for the Device Provisioning Service instance. 例如: {Scope ID}/registrations/{Registration ID}For example, {Scope ID}/registrations/{Registration ID}
{expiry}{expiry} 从纪元 1970 年 1 月 1日 00:00:00 UTC 时间至今秒数的 UTF8 字符串。UTF8 strings for number of seconds since the epoch 00:00:00 UTC on 1 January 1970.
{URL-encoded-resourceURI}{URL-encoded-resourceURI} 小写资源 URI 的小写 URL 编码Lower case URL-encoding of the lower case resource URI
{policyName}{policyName} 此令牌所引用的共享访问策略名称。The name of the shared access policy to which this token refers. 使用对称密钥证明预配时使用的策略名称是“注册” 。The policy name used when provisioning with symmetric key attestation is registration.

当设备使用单个注册进行证明时,设备将使用在单个注册条目中定义的对称密钥创建 SAS 令牌的哈希签名。When a device is attesting with an individual enrollment, the device uses the symmetric key defined in the individual enrollment entry to create the hashed signature for the SAS token.

有关创建 SAS 令牌的代码示例,请参阅安全令牌For code examples that create a SAS token, see Security Tokens.

Azure IoT C SDK 支持创建对称密钥证明的安全令牌。Creating security tokens for symmetric key attestation is supported by the Azure IoT C SDK. 有关使用 Azure IoT C SDK 来证明单个注册的示例,请参阅使用对称密钥预配模拟设备For an example using the Azure IoT C SDK to attest with an individual enrollment, see Provision a simulated device with symmetric keys.

组注册Group Enrollments

预配时,设备不直接使用组注册的对称密钥。The symmetric keys for group enrollments are not used directly by devices when provisioning. 属于注册组的设备使用派生的设备密钥进行预配。Instead devices that belong to an enrollment group provision using a derived device key.

首先,为通过注册组进行证明的每个设备定义一个唯一注册 ID。First, a unique registration ID is defined for each device attesting with an enrollment group. 注册 ID 的有效字符为小写字母数字和短划线(“-”)。Valid characters for the registration ID are lowercase alphanumeric and dash ('-'). 此注册 ID 应是标识设备的唯一 ID。This registration ID should be something unique that identifies the device. 例如,旧设备可能不支持多种安全功能。For example, a legacy device may not support many security features. 旧设备可能只有可用于唯一标识该设备的 MAC 地址或序列号。The legacy device may only have a MAC address or serial number available to uniquely identify that device. 在这种情况下,注册 ID 可由类似于以下内容的 MAC 地址和序列号组成:In that case, a registration ID can be composed of the MAC address and serial number similar to the following:

sn-007-888-abc-mac-a1-b2-c3-d4-e5-f6

如何使用对称密钥预配旧设备一文中使用了该示例。This exact example is used in the How to provision legacy devices using symmetric keys article.

为设备定义注册 ID 后,注册组的对称密钥用于计算注册 ID 的 HMAC-SHA256 哈希,以生成派生的设备密钥。Once a registration ID has been defined for the device, the symmetric key for the enrollment group is used to compute an HMAC-SHA256 hash of the registration ID to produce a derived device key. 可使用以下 C# 代码执行注册 ID 的哈希处理:The hashing of the registration ID can be performed with the following C# code:

using System; 
using System.Security.Cryptography; 
using System.Text;  

public static class Utils 
{ 
    public static string ComputeDerivedSymmetricKey(byte[] masterKey, string registrationId) 
    { 
        using (var hmac = new HMACSHA256(masterKey)) 
        { 
            return Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes(registrationId))); 
        } 
    } 
} 
String deviceKey = Utils.ComputeDerivedSymmetricKey(Convert.FromBase64String(masterKey), registrationId);

然后使用生成的设备密钥来生成要用于证明的 SAS 令牌。The resulting device key is then used to generate a SAS token to be used for attestation. 注册组中的每个设备都需要使用从唯一派生密钥中生成的安全令牌进行证明。Each device in an enrollment group is required to attest using a security token generated from a unique derived key. 注册组对称密钥不能直接用于证明。The enrollment group symmetric key cannot be used directly for attestation.

派生设备密钥的安装Installation of the derived device key

理想情况下,在中心中派生和安装设备密钥。Ideally the device keys are derived and installed in the factory. 此方法可保证不会在部署到设备的任何软件中包含组密钥。This method guarantees the group key is never included in any software deployed to the device. 向设备分配 MAC 地址或序列号后,可以派生密钥,并将其注入到设备,而无论制造商选择以何种方式来存储它。When the device is assigned a MAC address or serial number, the key can be derived and injected into the device however the manufacturer chooses to store it.

请考虑下图,该图显示了一个设备密钥表,这些设备密钥通过以下方式在中心中生成:通过组注册密钥 (K) 对每个设备注册 ID 进行哈希处理 。Consider the following diagram that shows a table of device keys generated in a factory by hashing each device registration ID with the group enrollment key (K).

从中心分配的设备密钥

每个设备的标识由注册 ID 和在中心安装的派生设备密钥表示。The identity of each device is represented by the registration ID and derived device key that is installed at the factory. 设备密钥不会复制到其他位置,且组密钥不会存储在设备上。The device key is never copied to another location and the group key is never stored on a device.

如果未在中心中安装设备密钥,应使用硬件安全模块 HSM 来安全存储设备标识。If the device keys are not installed in the factory, a hardware security module HSM should be used to securely store the device identity.

后续步骤Next steps

了解对称密钥证明后,请参阅以下文章以了解更多信息:Now that you have an understanding of Symmetric Key attestation, check out the following articles to learn more: