开发人员和嵌入式系统设计人员如何使用JWT关闭物联网设备的安全漏洞？

　　尽管人们越来越意识到对安全性的需求，但开发人员经常发现自己在安全性方面做出了快捷方式，将物联网设备连接到云端。在许多情况下，合适的安全机制的复杂性，微型电池供电的物联网设备中可用的有限内存和处理资源以及运输产品的需求之间的冲突似乎是不可克服的。
　　为了解决这些问题并简化物联网设备中安全功能的实现，Microchip Technology和Google合作创建了一种方法，将Microchip的安全硬件功能与称为JSON Web令牌（JWT）的简单数据结构相结合。结果是确保物联网设备与Google Cloud IoT核心服务之间相互身份验证的简便方法。
　　本文将介绍物联网设备安全威胁，并介绍目前用于应对该威胁的设备。它将确定安全漏洞以及开发人员和嵌入式系统设计人员如何使用JWT关闭它们。
　　物联网设备的安全漏洞
　　对物联网设备的攻击可以采取多种形式，绝不仅限于大规模物联网部署。即使是最小的物联网网络也是黑客寻求利用用于分布式拒绝服务（DDoS）攻击的僵尸网络中许多单个设备资源的有吸引力的目标。因此，每一类物联网设备的设计者都不可避免地要面对使用能够阻止攻击的强大的基于硬件的安全机制来保护其系统的必要性。
　　例如，使用系统内存或闪存存储用于加密和身份验证的私钥会使IoT设备容易受到攻击。更糟糕的是，黑客可以窃取这些密钥并使用它们来访问物联网网络和附加的公司资源。
　　安全IC
　　Microchip Technology的CryptoMemory和CryptoAuthentication IC等专用安全设备具有基于硬件的机制，可保护私钥和其他秘密数据。 EEPROM阵列集成在这些设备中，提供安全存储，只能通过设备的SPI或I2C串行接口访问的加密安全机制来实现（图1）。因此，这些设备提供了一种简单的方法，可以为任何物联网设备设计添加安全存储和其他安全功能。
　　
　　图1：Microchip Technology硬件安全设备（如AT88SC0204C CryptoMemory IC）提供安全存储，使用集成的加密机制来保护对片上EEPROM的访问。 （图片来源：Microchip Technology）
　　Microchip CryptoAuthentication系列的成员（如ATECC608A）通过支持安全设计中常用的加密算法，增强了安全存储基础。在其硬件功能中，该器件具有多种算法的硬件加速功能，包括：
　　非对称加密算法：
　　FIPS186-3椭圆曲线数字签名算法（ECDSA）
　　FIPS SP800-56A椭圆曲线Diffie-Hellman（ECDH）
　　NIST标准P256椭圆曲线加密（ECC）
　　对称加密算法：
　　SHA-256哈希加密
　　基于散列的消息验证代码（HMAC）加密
　　AES-128密码学
　　AES-GCM（伽罗瓦域乘法）密码术
　　密钥派生函数（KDF）：
　　伪随机函数（PRF）KDF
　　基于HMAC的提取和扩展KDF（HKDF）
　　对于加密专家而言，这组加密功能代表了支持更高级别安全协议进行身份验证和安全数据交换所需的全面机制列表。例如，KDF功能提供了传输层安全性（TLS）协议所需的基本机制，用于在交换甚至开始之前验证数据交换会话中的参与者。
　　在此协议中，TLS会话开始于客户端向服务器发送启动安全会话的请求。服务器使用其数字证书进行响应，客户端使用该证书来确认服务器的身份。在客户端以这种方式验证服务器之后，会话设置继续进行，客户端通过使用服务器的公钥来生成会话密钥，以加密使用PRF KDF或更强大的HDKF创建的一些随机值。
　　TLS身份验证协议是Internet安全的基础。称为证书颁发机构（CA）的整个证书提供商行业已经发展为支持安全通信的这一关键组件。公司从CA获得可信证书以在其自己的服务器上安装，以支持上述标准TLS服务器认证协议。
　　对于物联网应用，网络与公司来源广泛而深入地连接，这种单向认证不足以确保保护。例如，具有欺诈性证书的黑客可能将自己视为物联网设备的合法服务器，这是更广泛攻击的一部分。
　　尽管存在风险，但物联网开发人员通常很难实施TLS相互身份验证协议，因为使用TLS实现客户端身份验证所需的证书，密钥和软件可能超出许多物联网设备的功能。通过合作，Microchip Technology和Google创建了一种替代方法，将ATECC608A功能与称为JSON Web令牌（JWT）的简单数据结构相结合。结果是确保物联网设备与Google Cloud IoT核心服务之间相互身份验证的简便方法。
　　基于JWT的身份验证
　　在RFC 7519中规定，JWT是一个行业标准容器，用于提供有关准备和传输JWT的实体的信息，称为声明。 JWT结构本身包括三个部分：
　　标题，包括JSON名称：密码算法的名称（“alg”）的值对（例如，使用NIST P-256曲线的ECDSA的“EC256”），用于对令牌和类型进行签名（“typ”令牌的“）（这些令牌的”JWT“）
　　Payload，包括每个声明的JSON名称：值对
　　签名，使用标头中指定的算法对密钥以及标头和声明集进行编码，每个密码在加密前分别转换为base64 URL编码表示
　　RFC 7519为在有效负载或其他部分中指定声明提供了很大的灵活性。该标准甚至允许在没有签名或加密的情况下创建的不安全的JWT，在这种情况下，标头将包括算法的名称：值对{{alg“：”none“}。对于与Google Cloud IoT核心服务一起使用的JWT，Google需要签名部分以及具有三个强制声明的有效负载，包括：
　　“iat” - 以ISO 8601 UTC时间戳格式创建令牌时的“颁发时间”，自1970-01-01T00：00：00Z以来的秒数（例如，格林尼治标准时间2019年6月30日下午12:00:00 1561896000） ）
　　“exp” - 指定令牌过期的UTC时间戳，最大24小时超过“iat”值加上10分钟宽限期，以说明不同客户端和服务器之间的系统时钟偏差（例如，2019年7月1日的1561982400 12 ：格林威治标准时间00:00
　　“aud” - 包含开发人员Google Cloud项目ID的字符串
　　Google的物联网设备身份验证方案将基于TLS的常规服务器身份验证与使用这些相对简单的声明创建的JWT的物联网设备身份验证相结合。要启动新会话，IoT设备会打开一个到服务器的安全套接字，并使用前面描述的相同TLS协议对服务器进行身份验证。
　　此过程的下一步依赖于Google IoT云对物联网网络事务使用轻量级消息队列遥测传输（MQTT）协议。使用安全套接字到经过身份验证的服务器，IoT设备使用其唯一的JWT作为登录密码“登录”到该服务器的MQTT主机服务（清单1）。
　　/* Populate the buffer with the username */int config_get_client_username（char* buf， size_t buflen）{ if（buf && buflen） { int rv = snprintf（buf， buflen， “unused”）; if（0 《 rv && rv 《 buflen） { buf［rv］ = 0; return 0; } } return -1;} /* Populate the buffer with the user‘’s password */int config_get_client_password（char* buf， size_t buflen）{ int rv = -1; if（buf && buflen） { atca_jwt_t jwt; uint32_t ts = time_utils_get_utc（）; rv = atcab_init（&cfg_ateccx08a_i2c_default）; if（ATCA_SUCCESS ！= rv） { return rv; } /* Build the JWT */ rv = atca_jwt_init（&jwt， buf， buflen）; if（ATCA_SUCCESS ！= rv） { return rv; } if（ATCA_SUCCESS ！= （rv = atca_jwt_add_claim_numeric（&jwt， “iat”， ts））） { return rv; } if（ATCA_SUCCESS ！= （rv = atca_jwt_add_claim_numeric（&jwt， “exp”， ts + 86400））） { return rv; } if（ATCA_SUCCESS ！= （rv = atca_jwt_add_claim_string（&jwt， “aud”， config_gcp_project_id））） { return rv; } rv = atca_jwt_finalize（&jwt， 0）; atcab_release（）; } return rv;}清单1：包含在用于Google Cloud Platform IoT Core的Microchip Technology软件样本存储库中，该模块提供了用于生成虚拟用户名和JWT对象的例程，以用作使用MQTT主机进行客户端身份验证的密码。 （代码来源：Microchip Technology）
　　虽然IoT设备发送用户名作为此登录序列的一部分，但用户名不用于身份验证。因此，传输了一个虚拟用户名（清单2）。相反，IoT设备的认证基于作为登录密码发送的JWT进行。由于JWT签名是标头，有效负载和设备私钥的组合，因此Google Cloud IoT核心服务可以验证JWT是否真正来自授权设备。对于此验证，Google Cloud IoT服务使用以前由IoT设备开发人员使用下述密钥管理流程存储在Google云中的设备公钥。与单独使用TLS相比，此方法通过混合方法提供了相互身份验证，从而加快了流程，同时降低了IoT设备资源需求。
　　/* Connect the MQTT Client to the host */static int client_connect（void* pCtx）{ MQTTPacket_connectData mqtt_options = MQTTPacket_connectData_initializer; struct _g_client_context* ctx = （struct _g_client_context*）pCtx; size_t buf_bytes_remaining = CLIENT_MQTT_RX_BUF_SIZE; mqtt_options.keepAliveInterval = MQTT_KEEP_ALIVE_INTERVAL_S; mqtt_options.cleansession = 1; /* Client ID String */ mqtt_options.clientID.cstring = （char*）&ctx-》mqtt_rx_buf［0］; if（config_get_client_id（mqtt_options.clientID.cstring， buf_bytes_remaining）） { return MQTTCLIENT_FAILURE; } /* Username String */ mqtt_options.username.cstring = mqtt_options.clientID.cstring + strlen（mqtt_options.clientID.cstring） + 1; buf_bytes_remaining -= （mqtt_options.username.cstring - mqtt_options.clientID.cstring）; if（config_get_client_username（mqtt_options.username.cstring， buf_bytes_remaining）） { return MQTTCLIENT_FAILURE; } /* Password String */ mqtt_options.password.cstring = mqtt_options.username.cstring + strlen（mqtt_options.username.cstring） + 1; buf_bytes_remaining -= （mqtt_options.password.cstring - mqtt_options.username.cstring）; if（config_get_client_password（mqtt_options.password.cstring， buf_bytes_remaining）） { return MQTTCLIENT_FAILURE; } return MQTTConnect（&ctx-》mqtt_client， &mqtt_options）;}清单2：在Microchip软件样本库中提供，此函数演示如何使用JWT对象作为密码，在初始连接阶段对MQTT服务器的IoT设备进行身份验证。 （代码来源：Microchip Technology）
　　关键促成因素
　　ATECC608A及其供应链的功能是这种方法的关键推动因素。虽然任何MCU最终都可以从JWT报头和有效负载生成加密加密签名，但任何仅使用软件执行的方法在没有基于硬件的安全密钥存储的情况下仍然容易受到攻击。此外，对于许多资源有限的物联网设备或具有严格响应时间要求的应用，“仅软件”实现所需的处理器负载和执行延迟可能是禁止的。最后，没有丰富的安全算法和更高级别协议经验的开发人员将难以实现所需的软件功能。 Microchip通过其CryptoAuthLib库解决了这些问题（图2）。
　　
　　图2：由于CryptoAuthLib使用硬件抽象层（HAL）将API函数和核心基元与底层硬件分开，因此开发人员可以将其软件定位到各种支持设备。 （图片来源：Microchip Technology）
　　Microchip CryptoAuthLib简化了安全IoT功能的实现，例如Google JWT身份验证协议，将复杂的安全操作简化为通过CryptoAuthLib应用程序编程接口（API）提供的一组函数调用。对于物联网开发人员而言，最重要的可能是Microchip CryptoAuthLib核心功能充分利用了诸如ATECC608A之类的Microchip加密IC，可加快设计中安全功能的执行速度。例如，清单1中对atca_jwt_finalize（）的调用使用可用的加密设备（如ATECC608A）来创建清单2中用作密码的JWT。在这种情况下，ATECC608A加速JWT签名的加密，读取设计的私有从其集成的安全存储中获取密钥，以完成前面描述的签名创建过程。
　　然而，即使使用复杂的软件和安全设备，由于传统上管理密钥和证书所需的方法，物联网设备仍然容易受到攻击。过去，私钥需要在外部生成并在制造，分发甚至部署期间加载到安全存储设备中。即使使用硬件安全模块和安全设施，这些秘密在“需要知道”它们的唯一设备之外的短暂存在代表了一种安全弱点，可能导致其意外或意图暴露。通过利用ATECC608A的功能，Microchip和Google在很大程度上消除了传统的安全漏洞。
　　在这种新方法中，Microchip使用ATECC608A生成密钥对的能力，而私钥不会离开设备（图3）。然后，Microchip使用中间证书对设备生成的公钥进行签名，该证书由客户提供并存储在Microchip安全设施内的安全服务器中。最后，Microchip安全地将公钥传输到Google Cloud IoT设备管理器中的客户帐户，该设备管理器可为每个设备存储最多三个公钥，以支持密钥轮换策略。部署后，IoT设备可以使用ATECC608A安全功能来创建前面描述的相互身份验证过程中使用的JWT。
　　
　　图3：Microchip Technology和Google Cloud IoT服务相结合，简化了密钥和证书的配置，提供了一种旨在加强IoT应用安全性的受保护机制。 （图片来源：谷歌）
　　Microchip与Google之间的这种合作使开发人员可以完全卸载这一关键密钥管理流程。对于自定义要求，开发人员可以使用CryptoAuthLib API函数atcab_genkey（）实现自己的密钥管理过程，这会导致ATECC608A生成密钥对，将私钥存储在其安全存储中，并返回关联的公钥。
　　为了探索密钥生成和其他ATECC608A安全功能，开发人员可以快速建立一个围绕Microchip SAM D21 Xplained Pro评估套件构建的综合开发环境。 SAM D21 Xplained Pro套件基于Microchip ATSAMD21J18A 32位Arm®Cortex®-M0 + MCU，提供完整的硬件平台，由Microchip高级软件框架（ASF）驱动程序和代码模块支持。
　　为了评估包括ATECC608A在内的CryptoAuthentication设备，开发人员可以简单地将CryptoAuth XPRO-B附加板插入Xplained Pro板的两个扩展头之一。 Microchip提供了用于评估CryptoAuthLib与ATECC608A的安全功能的示例软件。更进一步，开发人员可以将Microchip ATWINC1500-XPRO Wi-Fi附加板插入另一个标头，以运行Microchip示例软件，该软件演示了本文中描述的相互认证流程，包括TLS服务器认证和JWT设备认证。
　　结论
　　虽然物联网应用程序安全性带来了多种要求，但关键挑战通常在于为物联网设备和云资源实现相互身份验证。在资源有限的物联网系统中，传统协议可能超过可用内存和处理资源。利用Microchip Technology CryptoAuthLib库和ATECC608A CryptoAuthentication IC，开发人员可以实施基于JSON Web Tokens的更高效方法，将IoT设备安全地连接到Google Cloud IoT服务。