一种更简便的增强 Wi-Fi 连接式物联网设计安全性的解决方案---凯利讯半导体

来源:互联网 发布:重生星际淘宝主腐书网 编辑:程序博客网 时间:2024/05/18 00:40

  Wi-Fi 连接是许多物联网 (IoT) 设备的关键要求,也是黑客们最喜爱的攻击目标。薄弱的安全措施会导致设备在持续的网络通信过程中容易遭到入侵。更糟糕的是,物联网设备有可能在其生命周期的早期,即设备尝试加入受信任的网络时,便沦为攻击的牺牲品。

  利用 Texas Instruments 的双核无线 MCU,工程师可以轻松地增强物联网设备在其整个产品生命周期内的安全性,并支持多层端到端安全策略。


  安全组件

  要保证任何系统的安全性,都采用需要多层方法。尽管在诸多安全措施中,数据加密是最容易想到的,但它只是稳健安全策略的一个方面。类似中间人攻击的黑帽子方法在经加密的数据交换开始之前很早便已在利用任何可能的漏洞。事实上,安全的主机会对客户端进行验证,确保只有经授权的用户、设备或其他系统才能获得访问权。反过来,这些客户端也会对主机进行验证,以确认其身份。

  这种双向验证居于安全应用的核心位置,但它最终依赖于更基础的机制和策略。首先,密钥和既有的信任根是任何安全应用的基础构件。在互联网上常用的公钥基础架构 (PKI) 中,与私人密钥配对的公钥提供了必不可少的实体身份验证。X.509 证书标准在更广泛的上下文中封装了建构在证书链之上且记录了身份的实体公钥,为应用提供了扎实可靠的信任根。

  密钥、加密、X.509 证书和信任根的使用是构建安全应用的必要而充分的条件。基于这些组件构建关键系统,并增加中间件和应用级安全协议,便可满足苛刻的安全要求。但对于大多数应用而言,开发人员只需使用上述组件和某些最佳操作实践(例如启动和无线 (OTA) 更新)便能锁定安全性。

  而且,甚至这些“基本”安全组件就代表了其自身的复杂机制和策略组合。对于产品经理,创建复杂的安全组件与专注于应用的差异化功能之间很快就会出现冲突。这种情况下安全措施往往会退居其次,因为物联网开发人员很少有时间来获取与精英黑客针锋相对所需要的知识或经验。Texas Instruments 无线 MCU 提供了让上述二者公平竞争的单一器件。


  无线 MCU

  TI 的无线 MCU 中有一个 CC3220 双核器件,其中包括一个 ARM<® Cortex®-M4 内核和一个专用网络处理器内核,并带有集成式收发器。该 MCU 提供三种变体:CC3220R、CC3220S 和 CC3220SF。三者均附带 256 KB 片载 SRAM,用于在器件处于各种低功耗模式期间保持数据。CC3220SF 还集成了 1 MB 闪存,用于实现代码的原位执行,而将 SRAM 仅用于可写入数据。独立的片载 ROM 提供了全套 Wi-Fi 和互联网逻辑层,从而使网络处理器无需 M4 内核的介入,便能提供全套连接服务。或许对于物联网开发人员而言,最重要的是,该器件可运用其嵌入式无线功能及多种片载硬件安全机制,来支持以下所述的各种各样安全服务。

  除了安全连接以外,该 MCU 还提供了大多数物联网应用所需的全套外设和连接接口。该器件提供了一个四通道 12 位模数转换器 (ADC)、四个采用 16 位脉冲宽度调制 (PWM) 的定时器、看门狗定时器,以及全套接口,包括多达 27 个 GPIO、8 位并行相机、安全数字 (SD) 卡、SPI、I2C 和 UART 端口,以及 JTAG、cJTAG 和串行线调试 (SWD) 接口。

  对开发人员而言,在复杂的设计中使用此器件非常简单。工程师可在相对简单的设计中,利用该器件的多个接口选择来运用其广泛的功能(图 1)。TI 通过其 CC3220S LaunchXL LaunchPad 和 CC3220SF LaunchXL LaunchPad 开发套件进一步简化了物联网设计实施。除了硬件评估板以外,这些套件还包括一个完整的参考设计,其中包含了硬件原理图、软件开发套件 (SDK) 和示例软件。

  

用于 CC3220 无线 MCU 的 TI LaunchPad 开发套件示意图

  图 1:用于 CC3220 无线 MCU 的 TI LaunchPad 开发套件提供了一套完整的物联网评估系统,其中包括硬件参考设计和用于实现安全连接的软件。(图片来源:凯利讯半导体)


  安全连接

    CC3220 具备全套片载外设,设计要求简单,更像是一种专为像物联网这样的嵌入式应用而设计的集成式 MCU。但与其他高度集成的 MCU 不同,CC3220 针对各种各样的必要安全组件提供了片上支持,以帮助确保物联网应用中的端到端安全性。除了用于实现安全验证和会话安全性的功能以外,该器件的安全机制还能针对所有三种数据状态提供保护:适用于“静态数据”的安全存储;适用于“使用中数据”的防篡改和其他运行时安全措施;以及适用于“传输中数据”的安全交换(图 2)。

  

TI CC3220 MCU 示意图

  图 2:在 TI CC3220 MCU 中,网络处理器的固件利用集成的安全硬件来支持各种端到端安全性,覆盖加密存储、安全 Wi-Fi 访问,甚至是嵌入式安全 Web 服务器。(图片来源:凯利讯半导体)

  CC3220 MCU 也不同于许多旨在提供低层次安全机制(例如加密和验证)的 IC。该 TI MCU 基于如安全存储和硬件加速加密之类集成功能构建而成,可提供全套更高层次的服务,甚至包括嵌入式服务器。例如,该器件使用标准传输层安全 (TLS) 协议支持多达 6 个安全套接字,并使用这些套接字提供嵌入式 HTTPS 服务器。为实现安全的验证和数据交换,该器件的信任根证书目录提供了一种机制,来帮助确保与其他受信任主机和客户端的交互。在更广泛的层面上,开发人员还可以使用该器件为建立信任链的关键进程构建 TI 信任根。

  TI 的 SimpleLink MCU 软件开发套件 (SDK) 通过一个 API 提供了这些功能,该 API 将受硬件或固件支持的详细功能抽象为若干简单的调用。例如,开发人员可通过调用一个 API 例程连接到网络:

  sl_WlanConnect(access_point_name, name_length, MAC_address, security_parameters, optional_enterprise_parameters)

  并将 security_parameters 设为器件所支持的标准 Wi-Fi 安全协议之一。

  完成连接后,器件可以同样轻松地提供其更高层次的服务。例如,开发人员可使用一个简单的调用启动内部 HTTP 服务器:

  sl_NetAppStart(SL_NETAPP_HTTP_SERVER_ID)。

  除了 SL_NETAPP_HTTP_SERVER_ID 之外,其他保留的位图 ID 将会启动用于 DHCP(动态主机配置协议)、DNS(域名服务器)和 mDNS(多播 DNS)的嵌入式服务器。

  类似地,开发人员可使用简单的 API 调用来运用芯片内集成的基本安全机制。例如,CC3220S 和 CC3220SF 变体均支持将数据作为加密文件存储在闪存中的增强文件系统(图 3)。这些 MCU 以透明的方式对数据进行动态加密和解密,并且仅允许通过 API 进行访问。当在开发期间或在运行时创建了安全文件时,MCU 会创建四个不同的令牌,分别代表不同的访问权限:完全访问权(主令牌)、读/写访问权、只写访问权和只读访问权。

  

TI 的 CC3220S 和 CC3220SF 示意图

  图 3:TI 的 CC3220S 和 CC3220SF 提供了扩展的安全功能,包括闪存上的安全文件存储,以及包括锁定 JTAG 和调试端口的功能在内的扩展型调试安全性。(图片来源:凯利讯半导体)

  开发人员通过 API 调用(类似于面向文件的传统操作)使用此安全功能,只需一个用于相关安全令牌的额外参数。如列表 1 所示,开发人员将 API 调用 (sl_FsOpen) 与用于指示应创建安全文件的标志配合使用,创建了一个新文件。后续打开该文件的调用需要使用提供的令牌 (MasterToken)。要实现更精细的访问控制,开发人员可使用 API 调用 (sl_FsGetInfo) 来读取在文件创建期间创建的所有四个令牌。

  char* DeviceFileName = "MyFile.txt";

  unsigned long MaxSize = 63 * 1024; //62.5K is max file size

  long DeviceFileHandle = -1;

  _i32 RetVal; //negative retval is an error

  unsigned long Offset = 0;

  unsigned char InputBuffer[100];

  _u32 MasterToken = 0;

  // Create a file and write data.The file in this example is secured, without signature and with a fail safe commit

  //create a secure file if not exists and open it for write.

  DeviceFileHandle = sl_FsOpen(unsigned char *)DeviceFileName,

  SL_FS_CREATE|SL_FS_OVERWRITE | SL_FS_CREATE_SECURE | SL_FS_CREATE_NOSIGNATURE | SL_FS_CREATE_MAX_SIZE( MaxSize ),

  &MasterToken);

  Offset = 0;

  //Preferred in secure file that the Offset and the length will be aligned to 16 bytes.

  RetVal = sl_FsWrite( DeviceFileHandle, Offset, (unsigned char *)"HelloWorld", strlen("HelloWorld"));

  RetVal = sl_FsClose(DeviceFileHandle, NULL, NULL , 0);

  // open the same file for read, using the Token we got from the creation procedure above

  DeviceFileHandle = sl_FsOpen(unsigned char *)DeviceFileName,

  SL_FS_READ,

  &MasterToken);

  Offset = 0;

  RetVal = sl_FsRead( DeviceFileHandle, Offset, (unsigned char *)InputBuffer, strlen("HelloWorld"));

  RetVal = sl_FsClose(DeviceFileHandle, NULL, NULL , 0);

  列表 1:SimpleLink SDK API 能够使用熟悉的传递令牌(如 MasterToken)或标志(如用于创建安全文件的 SL_FS_CREATE_SECURE)的文件访问调用,让开发人员访问稳健的安全功能,如安全文件访问。


  简化配置

  在开发期间,全面的片载安全功能集大幅加快了创建更坚固耐用的物联网设备的速度。但在网络部署期间,如果物联网设备无法轻松连接到现有的 Wi-Fi 网络,则大型物联网应用的推出可能严重滞后于计划。

  在针对 Wi-Fi 网络的典型配置过程中,用户为设备配置加入网络所需的网络名称和安全凭据。在这一关键阶段,设备设置和初始化中出现的错误步骤可能导致设备无法连接或让设备容易遭受攻击。对用户而言,无论设备的操作功能如何,无法连接的设备都会被视为失败,而且已被隐蔽侵入的设备将成为入侵用户的整个设备网络的方便之门。

  相比传统的网络产品,物联网设备配置可能面临更为严峻的困难。只有很少的物联网设备包含用于提供配置信息的本地显示屏和键盘输入选件。使用像使用蓝牙、NFC,甚至 USB 这样的带外方法提供此信息在成本上可能不允许,而且会增加设计的复杂度。最后,大型物联网应用中过多的设备数量可能导致传统的配置方法不切实际。相反,将相同的 Wi-Fi 介质同时用于配置和普通操作,则提供了一种极具吸引力的解决方案。

  但在实践中,Wi-Fi 配置存在自身的逻辑和安全挑战。为简化用户的这一步骤,无线业界针对诸如 Wi-Fi 安全设定 (WPS) 之类标准进行了演进。有了 WPS,用户可输入一个个人识别码 (PIN) 或按下一个按钮(按钮连接,或 PBC)。

  WPS PIN 机制中发现的零日安全缺陷曾令多数采用这种方法的用户大失所望。相反,一种被称为 AP 模式的流行方法则使用设备的无线连接向用户收集安全凭据。这种情况下,设备将临时充当 Wi-Fi 接入点,建立一个专用网络。用户使用其移动设备连接到此网络,时间长度足够上传安全凭据即可。完成此配置步骤后,设备将切换至站模式并使用新提供的凭据访问无线网络。

  TI 为这些标准配置机制补充了自己的名为 SmartConfig 的专有机制。采用此方法时,用户只需将网络名称 (SSID) 和密码加载到其移动设备一次即可。附近的任何物联网设备都可以主动扫描检测安全的 SmartConfig 广播,并自动加载广播中包含的经加密的配置信息(图 4)。

  

完整的 TI SmartConfig 流图片

  图 4:在完整的 TI SmartConfig 流中,用户将输入配置信息,从其移动设备激活 SmartConfig 广播,然后依靠物联网设备自动查找 SmartConfig 配置数据。(图片来源:凯利讯半导体)

  完成后,基于 CC3220 的物联网设备可使用其嵌入式 Web 服务器来通知用户,或直接将其状态上传到基于云的配置日志。利用此方法,物联网开发人员可提供无需介入的配置过程,让信任的物联网设备找到自己的方法加入安全物联网应用网络。

  尽管 SmartConfig 有着明显的优势,但配置方法的选择可能还取决于其他多种因素,这些因素可能要求使用更传统的机制甚至多种方法的组合。TI CC3220 无线 MCU 通过支持多种配置方法提供了需要的灵活性。除了 AP 方法和 SmartConfig 以外,该器件还允许开发人员采用组合 AP 与 SmartConfig 的混合方法。这种情况下,物联网设备可扫描检测 SmartConfig 广播并响应与用户之间的 AP 类型的交互,或在 SmartConfig 配置失败的情况下自动切换至 AP 模式(同样参见图 4)。

  在其支持的任何配置方法中,网络处理器都会处理包括侦听 SmartConfig 广播和加载 SSID 及安全凭据在内的所有进程方面。主机的参与仅限于使用单一命令 WlanProvisioning:

  _i16 sl_WlanProvisioning(_u8 ProvisioningCmd, _u8 RequestedRoleAfterSuccess, _u16 InactivityTimeoutSec, char *pSmartConfigKey, _u32 Flags);

  ProvisioningCmd 来启动或(停止)该进程。如此一来,便会允许主机采用受支持的 CC3220 配置方法开始配置,或停止配置进程。以下详细说明此命令:

  RequestedRoleAfterSuccess 指示物联网设备在成功配置后应切换至站模式还是 AP 模式。

  InactivityTimeoutSec 指示设备何时应自动停止不完整的配置进程。

  pSmartConfigKey 提供用于在移动端加密配置凭据并在物联网设备端为其解密的安全密钥。

  Flags:它提供了在进程中使用的具体配置细节。

  最后,该调用将返回 STATUS_OK 或各种诊断错误消息。

  在此进程的移动端,TI 在一组适用于 Java、Android 和 iOS 的库中提供了其 SmartConfig API,以便开发人员在移动应用中嵌入配置进程。与物联网设备端一样,移动应用使用单一命令和 TI SmartConfig 类对象启动 SmartConfig 广播(列表 2)。

  try {

  smartConfig = new SmartConfig(smartConfigListener, freeData, passwordKey, paddedEncryptionKey,gateway, SSID, (byte) 0, "");

  } catch (SocketException e) {

  Log.e(TAG, "Failed to create instance of smart config");

  return;

  }

  列表 2:移动应用开发人员只需调用一次 TI SmartConfig 库就能在其智能手机或其他移动设备中调用 SmartConfig 配置。


  总结

  对物联网开发人员而言,安全的 Wi-Fi 连接和配置可能存在诸多挑战,既包括设计成本和复杂性,也包括最终部署。过去,由于上述挑战,开发人员被迫在应用功能与安全性之间做出艰难取舍。

  TI CC3220 无线 MCU 凭借其嵌入式安全连接功能,可大幅简化设备的设计和部署,使其能够在物联网应用中支持稳健的端到端安全性。

阅读全文
0 0
原创粉丝点击