消息队列遥测传输 （mqtt） 中基于 Json Web 令牌 （jwt） 的客户端身份验证外文翻译资料

英语原文共 16 页，剩余内容已隐藏，支付完成后下载完整资料

消息队列遥测传输 （mqtt） 中基于 Json Web 令牌 （jwt） 的客户端身份验证

Krishna Shingala

krishna.shingala@nordicsemi.no

August 2018

摘要

本文概述了JSON Web令牌（JWT）和传输层安全性 （TLS） 作为对 Internet 上事物进行身份验证的两种主要方法。JSON Web Token（JWT）目前广泛用于 OAuth和OpenId框架中的授权和身份验证。最近，Google Cloud IoT强制要求将JWT用于基于HTTP和消息队列遥测传输（MQTT）协议的客户端，这些客户端通过TLS安全地连接到云服务。MQTT是物联网设备中的首选协议，也是本文作为应用协议的主要关注点。另一个流行的云平台 Amazon Web Service （AWS） 使用 TLS 相互身份验证进行客户端身份验证。此处提供的两种方法之间的任何比较主要来自受约束的设备客户端角度。

1 引言

由 [RFC7519] 定义的 JSON Web 令牌 （JWT） 支持互联网上两方或多方之间的数字安全表示和声明交换。JSON Web 令牌 （JWT） 已在 OAuth 框架中使用，用于服务用户向第三方授予授权。此类授权使第三方应用程序能够访问服务上的用户资源。OAuth 框架广泛用于 Web 和移动电话应用程序，并在 [RFC6749] 中指定。JWT 在 OAuth 框架中的使用在 [RFC7521] 中指定。图 1 演示了 JWT 作为第三方应用程序用于获取用户对其他服务资源的授权访问权限的访问令牌的示例和简化用法。这里LinkedIn是第三方应用程序，它请求访问用户Gail帐户的联系人（资源）。

图 1：在 OAuth 中使用 JWT 作为访问令牌

OpenID Connect 扩展了 OAuth，并将 JWT 用于身份验证目的。OpenId Connect 规范可在 [OpenID] 上找到。Google Cloud现在已经引入了将JWT用于物联网协议消息队列遥测传输（MQTT）进行身份验证。MQTT 规范可在 [MQTT 3.1.1] 上找到。亚马逊网络服务（AWS）是另一种流行的云服务，它采用TLS客户端证书作为对连接到物联网服务的客户端进行身份验证的主要机制。本文讨论了使用 MQTT 进行身份验证的可用机制。

2 JSON 网络令牌

由 [RFC7519] 定义的 JSON Web 令牌 （JWT） 支持互联网上两方或多方之间的数字安全表示和声明交换。这些声明以 JavaScript 对象表示法 （JSON） 格式进行描述。然后，可以将声明加密为 JSON Web 加密 （JWE），或者可以使用 JSON Web 签名 （JWS） 进行数字签名或 mac 保护。[RFC7516] 中指定的 JWE。[RFC7515] 中指定的 JWS。JSON 格式在 [RFC8259] 中指定。

图 2 演示了 JWT 的示例用法，JWS 是特定的，用于编码一组声明。JWS由三部分组成：

bull; 标头，以 JSON 格式描述用于保护声明的基元。

bull; 有效负载或正文以 JSON 格式描述声明。

bull; base64url 编码标头和有效负载上的签名或消息身份验证代码。

图 2：在 OAuth 框架中使用 JWT 进行授权

JWT 的每个字段都采用 base64url 编码，并由 '.'分隔。base64url 在 [RFC4648] 中指定。索赔的发布者，所描述的'iss'字段是SiT Cafe Elektro和索赔的主题，由'sub'字段描述的是免费午餐。此外，索赔的签发时间由'iat'（签发于）字段描述。同样，索赔的到期时间在'exp'字段中编码。用于表示'iat'和'exp'字段值的时间格式由 ISO8601 标准定义。此处，免费午餐声明于 UTC 时间 2018 年 8 月 21 日星期二上午 10：05：50 发出，并于 UTC 时间 2018 年 8 月 21 日星期二中午 12：05：50 到期。这些声明是使用 HMAC 在共享密钥'蓝莓'下使用 SHA-256（HS256） 进行身份验证的消息。

HS256 方案使用相同的密钥进行签名和验证，是一种消息认证方案。基于公钥加密方案的签名方案使用签名密钥（签名者专用）对消息进行签名，并使用验证密钥来验证签名，从而对对等方进行身份验证。JWT 支持 RSA 和 ECDSA 方案。用于保护 JWT 的算法已在 [RFC7518] 中定义。在后面的部分中，当提到基于 JWT 的方案时，将隐含基于公钥的签名方案。

显然，JWT服务器对于发行数字代币非常有用，如果有效，可以交换访问服务。

重要的是要注意，JWS mus应在安全通道上交换，以避免被嗅探方窃取和滥用。传输层安全性 （TLS） 通常用于建立安全通道，以便将 JWS 作为访问令牌进行交换。

3 消息队列遥测传输协议

MQTT是信息社会的高级开放标准（OASIS）标准，是机器对机器通信的轻量级协议。所有计算机（称为客户端）都通过称为代理的中央服务器进行通信。发布-订阅模式用于代理和客户端之间的消息交换。客户端可以是发布者、订阅者或两者兼而有之。所有客户端在连接到代理时必须唯一地标识自己。图 3 描述了连接到代理的两个客户端。其中一个客户端是数据源并发布数据，而另一个客户端是订阅和订阅有关特定主题的消息的消息。

[MQTT 3.1.1] 定义了许多概念和机制，以检测非活动客户端、发布此类客户端的最后遗嘱和遗嘱、正常断开连接等。但是，此处仅介绍与客户端身份验证讨论相关的必要概念。

3.1 运输

MQTT 是通过 TCP 传输定义的。TCP 端口 1883 是为 MQTT 协议保留的。如果 TLS 用于保护客户端和代理之间的通信，则使用 TCP 端口 8883。

定义了适用于UDP传输的新规范，即用于传感器网络的MQTT（MQTT-SN）。有关详细信息，请参阅 [MQTT-SN 1.2]。本文不讨论此版本。

图 3：MQTT 协议概述

3.2 发布和订阅

客户机可以使用 MQTT 发布消息将数据发布到代理。代理同样可以通过发布消息向客户端发送数据。每个发布消息都包含一个主题字段，用于标识正在发布的数据，例如，数据是温度测量还是 GPS 是否可以根据主题进行隔离。同样，如果客户有兴趣接收某些测量值，那么它可以订阅其感兴趣的主题。主题和有效负载的长度各不相同。

该规范不强制要求任何主题或主题的格式。但是，它确实定义了订阅主题时允许的通配符。该规范也没有规定客户端应支持的任何有效负载格式。

因此，规范留给实现很多，客户端必须遵守它希望与之通信的经纪人。值得注意的是，两个客户从不直接交谈。

3.3 客户端身份验证和授权

[MQTT 3.1.1] 使用连接请求的用户名和密码定义连接到代理的客户端的可选认证。用于用户名和密码的基元是留给部署基于 MQTT 的服务的实体的实现选择。根据在代理上配置的访问控制策略，客户端可能有权仅发布和/或订阅某些主题。该规范确实提到了使用 TLS 相互身份验证方案对客户端进行身份验证。因此，并非所有身份验证方案都必须使用连接请求的用户名和密码字段。

身份验证和授权访问的选择留给实现，而不是规范强制要求的。MQTT 的一些实现明确了将许多实现留给实现的问题。默认情况下，这些实现允许未经身份验证的客户端将数据发布到使用 TLS 对服务器进行身份验证的经过身份验证的订阅客户端。因此，服务器的身份验证对订阅者几乎没有价值。

3.4 保持活力

该规范定义了由客户端发送到代理的定期保持活动状态消息。这旨在让代理检测由于电池故障、网络丢失或其他原因而无法再访问的任何客户端。

4 MQTT 客户端身份验证方案

MQTT的规范，允许实现特定的客户端认证方案。第 3.3 节已经将客户端身份验证和授权总结为 MQTT 规范 [MQTT 3.1.1] 中的 de[1]罚款。该规范主要侧重于客户端身份验证，而不是代理（服务器）身份验证。但是，假定可以使用 TLS 服务器身份验证方案实现服务器身份验证。

在讨论客户端身份验证方案之前，建议熟悉 TLS。了解TLS服务器和TLS客户端的证书身份验证对于了解某些方案的工作原理以及将它们与其他方案进行比较特别有用。TLS 的 1.2 版规范可在 [RFC5246] 上找到。[Col18] 提供了 TLS 的良好概述，并很好地总结了 TLS 的攻击。在 TLS 握手期间提供服务器和客户端身份验证的快速刷新的服务器。

由于规范留给了实现和选择，因此没有考虑和比较所有可能性。本研究仅限于比较下面列出的方案：

bull; 用户名和密码

bull; 使用 TLS 进行客户端身份验证

bull; 使用 JWT 进行客户端身份验证

对于后续部分，请注意服务（云）可能由许多组件组成。MQTT 代理等组件用于与实现 MQTT 客户端的传感器设备进行通信，用于维护用户身份、身份验证和授权信息的用户数据库或身份和访问管理 （IAM） 系统，用于注册用户的门户，用于监视来自客户端的用户数据和/或客户端状态的门户等。因此，该服务是各种组件的组合。但是，在本文中，仅考虑了两个组件：MQTT 代理和用户数据库或 IAM。请注意，对于客户端，代理对服务进行符号化。

4.1 用户名和密码

MQTT 规范 [MQTT 3.1.1] 在来自客户端的连接请求消息中规定了用户名和密码字段。这两个字段都是可选的。每个字段的存在在消息的标志字段中单独指示。有关详细信息，请参见 [MQTT 3.1.1] 的第 3.1 节。

图 4 提供了连接到基于 MQTT 的服务的客户机的简化视图，该服务使用用户名和密码字段进行身份验证。授权派生自用户名的身份验证。

图 4：MQTT 客户端身份验证：用户名和密码

4.2 先决条件

对于此身份验证方案，必须满足以下先决条件。

bull; 用户名和密码已注册到服务中。

bull; 已在客户端中设置了用户名和密码。

此方法过于简单，并要求客户端将其标识和机密共享给代理。而且，一旦凭据被泄露，任何机构都可以开始冒充客户端。如果必须真正使用此方案，那么，必须采取至少两个预防措施：

bull; 加密客户端和代理之间的通信。

bull; 在向服务器发送任何凭据之前对其进行身份验证。

这两个问题都可以通过使用带有服务器身份验证方案的TLS轻松解决。

请注意，此方法可能永远不会在商业上部署，但是，它可以作为理解如何通过简单使用用户名来授权代理上资源使用的良好基础。

应该注意的是，规范使用客户端 ID 和用户名作为不同的概念，而没有对预期用途进行太多阐述。其中一种解释可能是单个用户可以从多个设备登录。通过这种解释，人们可以争论身份验证是否真的是用户身份验证或客户端身份验证。

但是，要求客户端 ID 在客户端之间是唯一的，即使没有用户名字段，也可以提供密码字段。这样就可以打开单个客户端的身份验证。在规范中允许两种模型似乎是有意的。但是，这是主观的读者理解。

4.3 使用 TLS 的客户端身份验证

MQTT 代理依赖于 TLS 客户端证书来建立客户端的身份，并对其进行身份验证。访问控制策略基于客户端（公共证书）的身份应用。图 5 说明了在 MQTT 连接之前使用 TLS 进行身份验证的 MQTT 客户机的身份验证。此方法并非 MQTT 所独有，并且基于 TLS 的客户端身份验证可用于使用 TLS 建立安全通道的任何协议。此方法已广泛用于基于 HTTP 的应用程序。

图 5： MQTT 客户端身份验证：TLS 客户端身份验证

4.4 先决条件

对于此身份验证方案，必须满足以下先决条件。

bull; 为客户端预配了其私钥和公有证书。此外，还设置了根 CA 证书以对服务器进行身份验证。

bull; 客户端的公共证书已注册为服务，并附加了必要的访问控制策略。

Amazon Web Service （AWS） 云服务将此方法部署为默认和推荐的机制，以对基于 HTTP 和 MQTT 的客户端进行身份验证。在 AWS 中注册的客户端证书由 AWS 信任的根 CA 签名。实际上，AWS 基于地理区域实现其根 CA。AWS 使用的证书链不是很长。有关将设备与 Amazon Web Service （AWS） IoT 集成的文档，请访问 [AWS IoT]。特定于协议的文档可在 [AWS IoT： 协议] 上找到。有关安全性和身份的其他文档，请访问 [AWS IoT： 安全性]。

请务必注意，AW

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[589583]，资料为PDF文档或Word文档，PDF文档可免费转换为Word