Chris A. Ciufo，嵌入式系统工程部门主编
ARM® mbed™ 操作系统 (OS) 在 TechCon 2014 大会上正式发布之时便激发了我浓厚的兴趣。自那以后，ARM 接连发布了多项安全和安保相关产品公告，其中许多与物联网 (IoT) 有关。但是，迄今为止，如何以点带面、全面铺开仍然是一大难题。日前，我采访了 ARM 营销副总裁 Zach Shelby 以及高级产品营销经理 Diya Soubra，就 Cortex®-M 处理器进行了探讨，也由此获得了更清晰的了解。为帮助读者理解，我添加了一些幻灯片，这些幻灯片取材于 Peter Aldworth 的一份简报“确保 IoT 安全”。这份针对 ARM 的演示文稿的理念与 Hannes Tschofenig 撰写的“如何确保物联网的安全？”一文一脉相承（后者内容更宽泛且篇幅更长，您可以通过 Google 查找到这篇文章）。
在这次编辑和摘录的讨论中，我们阐述了以下主题 — 所有这些均以 ARM 的关键 IoT 安全前提“您无法信任大数据，除非您可以信任小数据”为基础。
- ARM mbed OS - ARM mbed uVisor - ARM mbed TLS - ARM Cortex 处理器及其如何实现安全性 - 安全生命周期管理
Chris “C2” Ciufo：确保物联网 (IoT) 的安全：就 ARM 而言，会有什么新的举措？
Diya Soubra：mbed OS 很快会发布 [参见下图]。我们将于 8 月底发布测试版本，但是我们不会大肆宣传。接下来，我们将在 TechCon 大会 [2015 年 11 月] 上发布此开源软件的稳定版本，并且将鼓励人们使用该版本生产 IoT 产品。
ARM 于 2015 年 8 月发布 mbed OS 的测试版本，并且预计于 2015 年底面向公众发布正式版本。
C2：请告诉我们，什么是 mbed OS？我看到了它的逐步发展，但是我得承认，我还没有完全弄清楚什么是 mbed OS。
Zach Shelby：mbed OS 正在重新定义嵌入式设备（如微控制器）的操作系统。过去，设计人员常常亲自挑选内核、添加 IP 网络和其他代码，而它有点类似于“大杂烩”[各种零件拼凑在一起]。mbed OS 的功能在于，它在 OS 内核顶层内置了所有通信功能和安全功能，包括设备安全、通信安全和生命周期安全。ARM 正在确保所有设备 [适用于 IoT] 运行 mbed OS 并拥有一定级别的通信互操作性和安全支持。
C2：您说的“生命周期”是指什么？
Shelby：当我们谈到生命周期安全时，通常是指在设备生命周期过程中执行的不同形式的设备管理。在早期阶段，我们将保证关键注入的安全。我们确保设备能够从根本上受到信任。然后，我们会使用不同密钥凭据以安全的方式引导设备进行服务。我们执行安全管理，查看设备的运行情况。之后您可以返回，并执行固件更新。您甚至可以返回至初始阶段，然后重新引导设备完成新服务。所有这些实际上可以使系统或设备拥有更长的生命周期，而非只能使用一次。 ARM 认为“IoT 安全”应包含生命周期、通信和设备安全。我想简要地介绍一下这几个方面[参见下图]。
ARM 将这三个领域视为确保 IoT（从设备到其他）安全最重要的方面。
C2：让我们再回到 mbed OS。它是否类似于或者将会类似于传统的 OS 或 RTOS（实时操作系统），或者它是否意味着在某人偏好的嵌入式操作系统顶层运行？
Shelby：mbed OS 是一个独立的操作系统。它不会位于任何系统的顶层。它位于裸机的顶层。
它包含能源调度程序、事件调度程序以及稍后将在路线图中提及的任务调度程序。默认情况下，我们极为关注能源，确保当您连接至互联网并执行不同任务时，能够最大程度地降低能耗。
mbed OS 与传统 RTOS 的目标截然不同。未来，我们还将支持多任务处理功能，这意味着您可以执行一些使用 RTOS 完成的事项。总之，我们不会将 mbed OS 定位为取代 RTOS，因为当您拥有实时需求时，RTOS 仍会在嵌入式领域发挥重要作用。因此，如果您想按照纳秒和毫秒要求实时控制实体设备，可能需要使用 RTOS。
我们还提供一款适用于 RTOS 合作伙伴的解决方案，因为我们拥有出色的 RTOS 生态系统，即 mbed 客户端。它旨在提供极为上层的通信功能，这些功能常见于 mbed OS 和不同 RTOS 中，例如云通信和通信安全。
因此，该客户端可在 RTOS 及 Linux 上运行，并且我们已确保运行 mbed OS 的设备与运行其他操作系统的设备之间可实现互操作性。上述两个操作系统将于 8 月底推出。
C2：您之前提到了“裸机”。那么我们先从裸机开始来探讨安全性问题。
Shelby：您是指确保设备自身的安全；我们应讨论一些硬件方面的内容。如果您从大局考虑，如果没有连接至互联网的设备，而仅仅拥有嵌入式设备，那么 [提及] 设备安全时，您最需要担忧的是如何确保设备上已有信息的安全 — 并且要担心物理安全。但是，当您开始讨论网络或互联网连接时，您需要开始关注我们之前讨论的通信安全和生命周期安全。如何远程管理设备：这确实存在差异。 我们的设备端安全解决方案为uVisor，它是mbed OS 中安全服务的一部分 [参见下图
]。
确保设备安全应从运行于 Cortex-M 处理器顶层的 ARM uVisor 安全服务开始。
C2：uVisor 执行哪些操作？
Shelby：在设备上，您希望确保操作安全，不影响其余的软件系统。在传统的 CPU 类型系统中，您经常通过某种分区来以不同方式执行操作。在嵌入式设备中，通常会忽略这一点，或者通过固件保护或 Cortex-A 嵌入式内核中的 TrustZone 来完成；或者整个设备成为安全设备，这就是我们看到的有关安全 [信用/交易] 卡方面的内容。因此，这里存在不同类别的安全元件，包括在 Cortex 上运行且可以防止被篡改的 SIM 卡。
这是额外层面的设备安全。我们在目前的 IoT 部署中不会看到此类情况，但是它可以针对特定垂直领域发生改变。我们有时会看到用于存储密钥的安全存储等事项，但是这并不能始终解决使用该密钥时所遭遇的问题，并且软件仍然易受攻击。因此，我们依然面临一个问题：如何确保软件在设备上运行时安全无虞？
ARM 认为这是一个非常重要的问题，因此我们得出了以下结论：凭借 ARMv7-M 架构（当前的 ARM Cortex®-M3 和 Cortex-M4 处理器），我们可以完全在软件中实施合理的软件分区策略，而无需额外的硬件功能。这就是 uVisor 所担当的角色。
C2：目前 MCU 本身可以安全地进行软件分区吗？
Shelby：是的。它采用了具有内存保护单元的 ARMv7-M 架构，所以我们要求您使用 MPU [内存保护单元]。我们大多数基于 Cortex-M3 和 Cortex-M4 的设备均具有 MPU。我们能够定义哪些软件例程可以在安全模式下执行，哪些软件不可以 [参见下图]。
ARM 的 uVisor 使用内存保护单元 (MPU) 将内存分区为不安全（公共）和安全（专用）内存空间，从而确保软件能够安全地在 Cortex-M3 和 Cortex-M4 处理器上运行。
我们可以在安全空间中存储密钥等敏感事物。我们也能够在安全空间中存储实际加密算法软件库。我们甚至还可以在其中存储用于加密加速器的安全驱动程序，以及之前讨论的用于确保生命周期安全的安全启动等事物。我们也可以在安全空间中管理启动和配置。因此，如果您在设备上运行非可信第三方应用程序，则无法访问该信息或更改该软件。
Soubra：补充一点。所有 Cortex-M 处理器均有内存保护单元 (MPU)。我想拿它和内存管理单元比较一下，后者通常用于 Linux 系统。Cortex-M 针对实时、确定性嵌入式应用，因此它只有内存保护单元。
MPU 允许您分隔内存区域，并定义可在任务级别访问的保护。也就是说，应用程序会认为：“这一部分属于我，那一部分属于您。”如果驱动程序位于受保护的区域，并且一些 IoT 应用程序尝试访问受保护的空间，则您会收到一条例外消息：“好吧，这个人正在尝试访问他无权访问的区域。”我们的大多数合作伙伴提供 MPU，因为它使软件更可靠，并且能够在使用 uVisor 的情况下确保软件安全无虞。
C2：Zach，uVisor 是否为一项新事物？ Shelby：它是一项新事物。这是我们首次推出的 mbed OS 的一部分。
Soubra：确实如此，因此市面上许多人使用 MPU。由于可以对其进行分区，因此它能使软件更加可靠。但是到目前为止，很难找到一位能够以此种方式将整个软件堆栈从操作系统一直向上构建至协议的开发人员。这就是 mbed OS 的功能，它能够向您提供通信协议、安全性、密钥加密处理功能以及 uVisor；您需要的功能一应俱全，并且它将位于内存保护单元技术的顶层。
这就是 mbed OS 的功能，它能够向您提供通信协议、安全性、密钥加密处理功能以及 uVisor；您需要的功能一应俱全，并且它将位于内存保护单元技术的顶层。
Diya Soubra，ARM 公司
C2：您之前定义了生命周期，我们能否重新回到该话题？我不确定能否跟得上您的思路。
Shelby：有些人会谈论设备管理。在 IoT 环境下，我们希望谈论安全生命周期管理，因为它将从一个更全面的角度描述这些设备所经历的整个生命周期。
我们目前正在将生命周期安全融入 mbed OS 的方方面面，并且我们会坚持不懈，因为我们大有所为。但是首先，我们极为看重管理协议标准，因此我们在 mbed OS 构建了轻量级 M2M 设备管理 [LWM2M] 标准。我们实际上支持在所有设备中使用该标准，并且它类似于蜂窝数据行业中用于远程管理蜂窝设备的标准。这是一项新标准；您可以使用该标准，通过线程网络或较慢的遥测网络之类的连接来管理非常小的设备。
C2：听起来，该领域还将涌现更多的新技术，因为您提到了配置、监控、预配置、启动及相关内容。
Shelby：这将会使我们在未来几年非常忙碌，因为随着这些 IoT 系统的用户和开发人员愈发成熟，我们必须记住安全领域有一个学习曲线。因此，推动我们奋力前进的一个主要因素在于，让人们了解此类安全功能、所需内容以及使用方式。坦白来讲，大量嵌入式设计现今并未充分利用这一安全功能。
通过以生命周期安全为基础，我们将构建启动功能等事项，以便您可以让设备从空白状态转为提供服务。我们目前能够远程执行配置和管理，这也包含在 mbed OS 中，因此您可以在 [设备] 运行时更改配置参数等事物。并且，我们将会发布安全远程更新功能。
C2：现在我们已经讨论了生命周期安全，那么让我们重新回到网络连接、通信以及连接的差异性。
Shelby：在通信安全方面，ARM 于今年收购了 Offspark 公司及其产品 PolarSSL。这是一款著名的嵌入式通信安全解决方案，面向真正的嵌入式设备。PolarSSL 提供的互联网级别安全设计针对微控制器级别的嵌入式设备。所有安全通信技术的基石是 TLS，而我们创建的 mbed TLS 软件则以 PolarSSL 技术为基础。
如果它用于 Web，则我们十分确信它在物联网方面也是安全的，因为我们应用了相同的标准 — 因此我们的 mbed TLS 软件也能实现这一目标，并且它将与 mbed OS 一起免费提供。它将于 8 月发布，任何人均可以使用。我们还认为，谈到 IoT 时，设备安全对于整个互联网至关重要，因此该软件也属于我们客户端的一部分，并且它可单独提供。作为确保 IoT 安全的一部分，我们鼓励每个人针对各种不同设备使用 mbed TLS。
C2：那么对于通信安全而言呢？
Shelby：您在确保通信安全时，如果正在使用密钥的公共部分，该密钥是您证书的一部分，则要在设备上执行一些操作。当您使用这些密钥执行安全操作时，您将处于易受攻击的状态。
也就是说：如果您正在使用密钥创建新的密钥，并且想要这些密钥在设备上处于专用状态，则当某人访问设备上运行的软件时，这些密钥将可用。这就是一个攻击面。
因此，我们在通信安全中执行的操作将受益于设备安全，从而使它们能从设备上运行的软件的安全分区中获益。您希望能够单独执行这些安全事项，而不影响其余软件的运行，尤其是人们可以在设备上下载或更改的事项。
以下是我的观点：[基于安全密钥管理] 的通信安全实际上将从设备安全中获益。您是否会看到这些部件如何全部整合在一起，以实现安全的 IoT 系统？我想说的另一方面是，我们可以从硬件加密中获益，例如合作伙伴提供的 Cortex 芯片产品。
Soubra：目前，市面上有多家供应商提供 IP，并且数家 IC 供应商提供的芯片可在硬件中添加加密加速器。尽管 Cortex-M 架构具备软件加密功能，但是用户仍能从硬件加密中获益。
例如，在 Cortex-M3 中，我们实际上拥有三个来自处理器的总线，而在系统总线中添加加密 IP 将能够释放代码和数据总线，因此当其他总线执行 I/O（包括加密）时，您只需运行代码即可获取数据。
C2：这是否仅针对 Cortex-M3？
Soubra：不是，2015 年发布的首款 mbed OS 将面向 Cortex-M3 和 Cortex-M4。加密可以通过专用块或软件在硬件中完成。
考虑到工作负载，在软件中执行加密时需要使用 32 位通用处理器；此外，请不要忘记，我们还要运行剩余的软件堆栈，而这是需要首先执行加密的主要原因。
C2：这些功能在 8 位或 16 位处理器上是否可行？
Shelby：这是个很好的问题。32 位架构对于实现软件加密也极为重要，因为系统各不相同。以往，嵌入式开发人员发现，在 8 位或 16 位架构上实现基于公共密钥的高级安全功能十分困难。
在这些较窄的处理器中，执行加密非常耗能。并且诸如证书处理等操作也会非常慢。它不适用于为实现真正的互联网安全而执行的各类操作。因此，如果是连接至实际上不需要安全性的极为专用的闭路系统，可能 8 位或 16 位处理器就可以了。但是，如果是真正连接至互联网，就需要加密，需要所有相关的安全措施，并且确实适合 32 位操作。
C2：其他处理器制造商是否就此与 ARM 达成了一致？
Soubra：我想分享一些与业内合作伙伴及客户交流时所了解的观点。他们认为，系统设计最困难的部分在于软件集成和推广。
因此，芯片提供商尝试节省成本时，都会说到“我将制造 8 位芯片，它将变得更小，并且它将适用于 IoT”，而最终，在 [系统至互联网] 环节会出现一种情况：芯片将被拒绝。如果给我一个 8 位芯片，并且告知我执行 TLS 以及连接至 Web 的所有这些协议，则可能要花费两倍或三倍的工程投入量来优化此设备中的所有代码。
因此，慢慢地，市场让所有芯片供应商明白了一个道理，即物联网实际上和互联网并无二致。如果您想要进入 IoT 市场，我们希望可以最大程度提高软件生产力，因为进入市场首先便要给您这个市场，并且没有人会拥有一个只开发软件的团队。简而言之：32 位处理器最能满足要求。
C2：我们在探讨 mbed 或安全性时，并未讨论更出色的互联网，例如基于云的 IoT 服务。如果从公司角度来看，您对节点这块有何评论？
Shelby：整体而言，有关 mbed 生态系统的另一主要事项即为，我们正在构建涉及大量合作伙伴的大型生态系统，这些合作伙伴负责制造开发板、芯片、模块、软件服务和设备。我认为这些合作伙伴数以千计。其中大部分均涉足了云平台领域。他们就是我们所说的云合作伙伴，并且他们是我们当前计划不可或缺的一部分。
我们实际上会说，“好的，我们将构建一个包含大量开发板、大量产品和大量云服务的生态系统，将共同协作，并且无须执行任何特殊事项。”开发板设计人员不必针对云服务 A 和云服务 B 执行特殊支持。您只需运行 mbed OS，即可获得更多的服务支持。它们均能够处理配置引导和确保安全，并且我们知道这些事务能够正常运行。
就在刚刚过去的 5 月，我们在旧金山的 MakerCon 大会上发布了新的 mbed Enabled 计划。这是一项免费的认证计划；我们可以借此确保合作伙伴提供的这些设备、开发板或最终产品以及不同的服务能够协调运行。
C2：我们的谈话即将进入尾声。您觉得有哪些要注意的关键点？
Shelby：我认为需要记住的一点是，对于 ARM 的合作技术和人员以及 mbed 生态系统而言，我们仍然深处在价值链中。我们与芯片提供商、开发板制造商、模块制造商、设备 OEM、ODM 以及云技术平台提供商展开合作。因此，我们正在技术层面而非即用型解决方案领域内开展工作。我们不向消费者销售产品，而您可以获得相当酷的、基于 mbed 开发的电灯泡，并搭配 mbed 电灯开关使用。
我们不是一家消费型公司，因此我认为区分各自的期望至关重要。但是，我们非常期望构建一个技术生态系统以及一个技术工具套件。构建系统的人员对此非常有信心：“我可以在此设备上运行 mbed OS。”这意味着，我知道它能够与这些其他 mbed 设备结合使用，并且可以与其他 mbed 云服务配合使用。它具备此级别的互操作性。
我仍需要以一个整体来设计系统；我需要增加附加值，并且我认为关于 mbed 技术平台最好的一点是，它是开放的。因此，它能够与 mbed 生态系统中的其他项目结合使用，但是它并不局限于此。您可能需在 mbed OS 顶层使用大量其他行业特定的标准，并且您可能需要额外的功能，针对行业的特殊要求（不论是什么），来创建解决方案。并且 mbed OS 或云合作伙伴不会限制您执行此操作。
Soubra：
唯一要补充的是，得让人们知道，我们不会错过任何细节。我们不会无所事事，被动等待新技术的出现，我们不会坐等他人来发明新的事物。这就是我们今天的分享。我们介绍了适用于多种 IoT
应用类型的分层安全解决方案。以 Cortex-M3 为例，对于配备 Cortex-M3 内核的设备市场，它将拥有大量的选择。您可以在其上安装并运行软件，以构建这些 IoT 解决方案。是的，正如 Zach 所说的那样，您还要构建这些解决方案，只要想做，没有什么能够阻止您实现目标。