一些重要的远程应用程序（如电子投票，在线银行，工业控制系统和医疗设备）依赖于通过Web应用程序执行的交互。在攻击者控制用户计算机的情况下，通往此类远程系统的可信路径往往至关重要。攻击者可以观察和修改任何IO数据，而不被用户或服务器检测到。本文提出PROTECT IO N作为解决方案，该系统使用被恶意控制主机和IO设备之间的低TCB受信任设备来确保IO完整性。PROTECT IO N采集来自键盘和鼠标的显示信号和用户输入，并将安全UI覆盖在不受信任主机所生成的HDMI帧之上。

一、现有防御方案的缺点

    现有的解决方案有两大类，它们解决了被攻击主机下的IO设备的可信路径问题，如图所示：

A类，首先发生未受保护的用户交互，然后使用可信组件来确保输入的完整性。

事务确认设备：事务确认设备要求用户使用单独的设备来确认输入参数。ZTIC之类的系统使用带有显示器和智能卡的外部设备来确保用户输入的完整性，Android OS也提供了类似的机制来确认受保护的事务。但是这些方法具有三个重大缺陷：

1）用户习惯化的风险—用户在不查看实际数据的情况下确认事务，

2）可用性–与小型设备交互可能很麻烦，

3）仅简单的UI可以支持–事务确认不适用于复杂的交互，而是简单的基于文本的输入。

B类，受信任组件获取用户的输入/输出，然后将其安全地传输到目标；受信任组件可以是系统管理程序，也可以是外部硬件。

1、基于受信任的虚拟机管理程序的解决方案：可信管理程序和安全微内核是实现可信路径的替代方法。SGXIO组合了TEE和虚拟机管理程序，以减轻SGX之类的TEE的缺点（例如，操作系统控制IO操作）。但是，基于虚拟机管理程序的解决方案需要很大的TCB。由于经过验证的虚拟机管理程序只能提供有限的功能，因此对于普通用户而言不切实际。提供了丰富功能的虚拟机管理程序的代码大小已经与实际OS相当。

2、基于外部硬件的解决方案：现有的一些方案提出了一种利用外部可信设备的可信路径。IntegriKey使用受信任的外部设备，它包含一个程序，该程序对所有用户输入进行签名，并将签名的输入发送到远程服务器。当远程服务器验证签名输入是否与运行在不受信任主机上的浏览器发送的输入匹配时，该设备将成为输入完整性的第二个因素。但是，由于外部设备完全忽略了不受信任的主机提供的显示信息，因此不仅IntegriKey以及不考虑输出完整性的类似系统都容易受到UI操作攻击。

    例如，假设用户对文本框的预期输入是100。他输入了正确的值，但是主机通过不显示最后一个0来恶意地在屏幕上呈现10。考虑到他自己可能输入了错误，用户键入了另一个0，使来自用户的输入达到1000。此攻击违反了输入完整性，因为主机现在可以将1000作为有效输入提交给远程服务器，尽管它不代表用户的输入意向。

    Fidelius*使用外部设备和在SGX安全区中运行的JavaScript解释器来保护键盘输入不受恶意浏览器的攻击。Fidelius会在显示画面上保持覆盖，尤其是在输入文本框上，以隐藏浏览器中敏感的用户输入。

    但是Fidelius要求用户不断监控不同的安全指标（两个LED灯和屏幕上的状态栏）以确保输入内容的完整性和机密性，从而给用户带来很大的认知负担。此外，攻击者可以操纵UI元素的标签，以欺骗用户提供错误的输入。缺少鼠标支持（可能仅表现为功能限制）使Fidelius能遭受到提前表单提交攻击，即在用户填写表单的所有字段之前，主机可以模拟鼠标单击“提交”按钮。这使攻击者可以在输入不完整的情况下尽早提交表单，违反了完整性。 

3、基于TEE的系统解决方案：VButton使用ARM TrustZone（TZ）安全地呈现UI按钮并从中接收用户输入。这在移动设备上是可能的，因为TZ体系结构支持系统总线上的标志，该标志指示IO设备（如触摸屏）是与受信任的TZ应用程序还是不受信任的OS进行通信。但这样的解决方案也是不可行的，因为：

1）x86体系结构不支持IO外设与TEE应用程序（如SGX enclaves）之间的安全通信– 86中的类似系统将需要更改系统体系结构，TEE体系结构和IO设备。

2）此类解决方案需要TEE感知应用程序，并且不适用于当前的浏览器。

    现有系统的缺点表明，在存在不受信任的主机的情况下确保IO的完整性和机密性是一个不小的问题，需要全面的解决方案。所有以前的可信路径解决方案既不能同时保护输入和输出，也不会考虑不同的输入方式。

由此得到三个观察：

观察 1：缺乏输出完整性 —>屏幕上呈现用户输入—>损害了输入完整性。

观察 2：如果输出保护是在上下文之外提供的，用户更有可能不对其进行验证。因此sh输入的完整性可能受到损害。

观察 3：如果不能同时确保所有输入方式的安全性，则不能完全确保它们中任何一个的安全性。

二、系统主要技术

 1、系统和攻击模型

    考虑一种典型的情况，即用户希望通过攻击者控制的主机与受信任的远程Web服务器进行交互，下图中描述了该模型。仅假设显示器，键盘，鼠标（总之，需要保护免受恶意主机攻击的所有IO设备）和IOHUB是可信任的。

     IOHUB充当所有IO设备和主机之间的中介。请注意，IOHUB不具有直接与服务器通信的网络功能，而是依靠主机将其用作不受信任的传输。还假定IOHUB附带了预加载的证书和密钥，这些证书和密钥使IOHUB可以验证服务器签名的签名和签名数据（例如用户输入）。

    有许多可能方式来部署PROTECT IO N。一种方法是假定IOHUB制造商为每个已部署的IOHUB颁发证书。IOHUB会为远程服务器及其公共证书维护白名单。这允许IOHUB验证由那些远程服务器签名的消息。另一个假设可能是IOHUB由同时运行远程服务器的服务提供商发布。

2、系统保护的高级描述

    仅当用户访问需要保护安全性的敏感Web应用程序时，IOHOB才处于活动状态。最初远程服务器以IOHUB可以理解的格式，对敏感的UI元素进行签名并将其交付给主机。接下来，主机将敏感的UI传输到IOHUB，并且IOHUB验证签名以防止主机进行操作。从下图所示的示例中可以看出，IOHOB然后将带有敏感元素的UI渲染到从主机接收到的HDMI帧上方的覆盖层中。

    主机无法访问或修改IOHUB生成的覆盖图。此外，覆盖层仅覆盖屏幕的一部分，从而使网页上其他功能丰富的内容可以不修改地运行。因此可以确保将敏感的UI元素按远程服务器的期望呈现给用户-输出完整性。对于覆盖层，使用QR码将数据从主机传输到设备，避免在单独的通道上使用额外的软件/硬件，并且易于查看。

    当用户与覆盖层交互（键入或移动鼠标）时，IOHOB不会将任何事件从键盘或鼠标转发到主机。交互仅由IOHUB维护，IOHOB呈现屏幕上的用户输入，因此提供的用户体验与典型的用户体验相同，就好像没有IOHUB。

    用户单击“提交”按钮将触发提交过程，该过程由IOHUB签署用户输入并发送到服务器组成。请注意，表单的文本字段和“提交”按钮位于主机无法访问的覆盖内，因此攻击者无法执行提前表单提交或点击劫持攻击。最后，服务器验证IOHUB的签名，以确保主机未更改数据。由此IOHOB确保所有输入方式的输入完整性。

三、IO完整性保护

1、UI元素的 IOHUB 覆盖

    输出和输入完整性必须都得到保护，以此保护它们中的任何一个。PROTECT IO N通过隔离显示器中不受信任的主机无法观察或修改的一部分来确保输出完整性。IOHUB拦截来自主机的HDMI帧，然后在屏幕上注入敏感UI的渲染。该覆盖图可提供输出完整性，因为它可以阻止攻击者在其上方绘制内容，以欺骗用户提供错误的输入。

    为了最大地减少TCB，IOHUB不运行浏览器，即它不能解释或呈现HTML，JavaScript等。相反，IOHUB附带了一个小的解释程序，类似于浏览器在功能上呈现引擎，但由于它只呈现有限数量的HTML，解释器常规读取给定的规范并呈现相应的UI。该规范是一个简单的JSON文件，用于定义应如何呈现覆盖层的内容，例如元素数量，顺序，类型和标签。

    在屏幕上呈现覆盖层的过程分为两个阶段：

1）安全表单→规范：PROTECT IO N要求开发人员手动注释HTML代码中的敏感元素（如protect =“ true”属性）。然后，对于每个请求，保护服务器端组件都会解析HTML源，向form元素添加随机标识符（id），对其进行签名 ，然后将 signature 添加至表单并将其交付给用户的浏览器。该id用作会话标识，以防止攻击者重新提交用户的旧输入数据。

    在客户端，PROTECT IO N JS解析带标签的HTML源，并生成可以由IOHUB解释的规范。上图规范中提供了一个规范示例。在实现中，PROTECT IO N JS将规范编码为QR码。下图显示了步骤①和②之间的转换。步骤②由IOHUB在下一阶段处理，对用户不可见。

2）规范→覆盖： IOHUB执行下一个阶段，该阶段从检测HDMI帧中的编码规范（QR码）开始。然后，IOHUB验证签名，根据规范渲染覆盖图，并将其呈现给用户。 

    IOHUB覆盖图在上图中的③中显示，这是向用户显示的最终UI。请注意，由于IOHUB即时解码并覆盖了QR码，因此用户看不到QR码。

    IOHUB使用规范来确定用户与之交互的特定UI元素。当用户单击文本字段时，IOHOB允许用户输入输入内容。覆盖层中的UI元素仅从输入设备（鼠标和键盘）获取输入。因此，恶意主机无法注入或修改用户的任何输入。

2、集中用户注意力

    攻击者可以在显示空间的不受信任的部分上向用户显示虚假信息，这可能会影响他的输入。强大的对手可以制作恶意导向，并作为覆盖层的一部分呈现给用户。

    为了减轻这些攻击，采用了针对基于浏览器安全性的类似威胁所提出的技术。这些技术的目标是将用户的注意力集中到与之交互的敏感UI元素上。第一种技术称为灯箱(Lightbox)，它使屏幕的非覆盖部分变暗，该部分是由不受信任的主机生成的。

    第二种技术包括当用户进入叠加的UI时冻结主机的显示帧。这样，恶意主机就无法通过显示动画或利用其他技巧来吸引用户的注意力。灯箱提供了更多的安全保证，因为它可以完全阻挡不受信任的屏幕，但对用户更具干扰性。尽管冻结的侵入性较小，但不会从屏幕上删除潜在的恶意信息。

3、在HDMI帧中连续跟踪鼠标指针

    注意力集中机制的触发给PROTECT IO N带来了艰巨的任务，因为IOHUB不知道鼠标指针的确切位置。不能依靠受感染的主机可靠地将指针位置传达给IOHUB。此外当用户与IOHUB渲染的叠加层进行交互时，主机的鼠标指针不可见，因为IOHUB始终在主机的HDMI帧上方绘制。

    IOHUB会拦截鼠标事件和HDMI帧，因此它可以基于鼠标数据跟踪指针，并将其与HDMI帧中的实际位置关联（使用小矩形中的形状检测）。然后，IOHOB会覆盖一个鼠标指针，该鼠标指针突出并且易于用户遵循。

4、受保护的用户交互

    以顺序图描述了用户的交互。上图说明了用户输入的传输过程。它具有两个阶段：记录和传输，如下所述：

1）记录：在将UI元素正确覆盖在屏幕上之后，用户可以与这些UI元素进行交互。用户与覆盖UI元素的交互与标准UI相同。UI规范对所有生成的UI元素的行为进行编码，从而使IOHUB知道UI对象的语义。例如，当用户选择一个文本框并用他的键盘键入时，IOHOB会拦截所有击键并在覆盖图上呈现字符。

    当用户在呈现的覆盖UI元素（例如文本框，按钮，滑块，单选按钮等）中输入输入数据时，IOHUB会在（键，值）对中记录该数据，其中键是UI元素的标识符（规范中的id），该值是用户提供的值。

2）传输：在传输阶段，IOHUB等待用户选择具有触发功能的UI元素，例如，Web表单上的提交按钮。触发元素可以更改覆盖表格的状态，例如，将表格的数据提交到远程服务器或将其重置。当用户单击“确定”按钮时，设备将使用其嵌入式私钥对“记录”进行签名。

    在从IOHUB接收到签名的输入数据后，如果签名验证成功，则远程接受输入。注意，如果将输入字段注释为protect =“ true”，则服务器将不接受没有IOHUB签名的任何输入。这样可以防止攻击者控制的主机提交数据。

四、IO机密性保护

    实现IO机密性的主要组件之一是在远程服务器和IOHUB之间建立安全通道（即TLS通道）。TLS确保不受信任的主机不会读取或修改用户与远程服务器之间交换的任何数据。

1、 IO操作

建立TLS： IOHUB和服务器使用公共证书创建TLS。TLS如第IV节所述，分别使用模拟的按键流和HDMI作为上游和下游通道。实施细节在第VII-A5节中提供。

输出机密性：输出机密性可确保从主机隐藏从远程服务器发送的信息以及用户输入的可视化呈现。为了实现输出保密性，对IV-A节中描述的UI覆盖机制进行了一些修改。不同之处在于该规范不是在客户端生成的，而是在服务器中生成的。一个与PROTECT**IO**NJS非常相似的小型服务器端模块将UI元素转换为UI规范，并使用TLS会话密钥对其进行加密。

    加密的规范在HTML文件的<encrypted_qr>标签内传递到客户端浏览器，然后由PROTECT**IO**N JS编码（作为QR码）。IOHUB从截获的HDMI帧中解码QR码，解密规范并相应地渲染覆盖图。HTML Snippet 2中提供了一个示例，其相应的UI如下图所示。PROTECT**IO**N的此功能允许远程服务器在受攻击主机（例如银行帐户对帐单或任何其他主机）的情况下向用户安全地发送私人信息或任何其他机密消息。

输入机密性：当用户将鼠标指针输入到覆盖的UI区域时，IOHOB会停止将任何鼠标或键盘事件传输到主机，从而使其在此期间完全没有任何鼠标移动或击键。但是，当IOHUB在覆盖的UI元素上呈现纯文本字符时，用户仍可以在屏幕上看到她的输入，因此使它们仅对用户可见。

    同样，当用户选择UI元素时，IOHUB将所选值存储在记录的数据中。提交表单时IOHUB使用TLS密钥加密记录的数据，并将其发送到远程服务器。

2、集中用户注意力

    IO机密性可以被视为与网络钓鱼类似的问题，在网络钓鱼中，向攻击者生成的UI（或网络钓鱼网页）提供输入会泄露敏感信息。类似于网络钓鱼保护机制，IO机密性要求用户给予额外的注意/操作。安全注意序列（SAS）是由用户执行的一系列值得信赖的操作（例如Windows中的按键Ctrl + Alt + Del）。SAS可以防止不受信任的系统触发对用户敏感的事件。请注意，在UI / UX设计的背景下，SAS是一个经过充分研究的主题。

    PROTECT IO N采用了现成的SAS机制，该机制为用户提供视觉帮助，以区分覆盖的UI和鼠标指针位置。SAS对于IO机密性至关重要，因为不受信任的主机可以欺骗用户以伪造形式输入其敏感信息。因此，用户需要记住SAS，以将IOHUB生成的UI与主机生成的UI区分开。请注意，自动激活还不够，因为在任何给定时间，主机都可能恶意模仿自动激活，以欺骗用户向非法UI提供敏感信息。

五、保护原型的实现

    上图分两部分描述了PROTECTION原型：图a显示了具有各种组件和连接的原型的框图，图b显示了实际原型的照片。IOHUB原型已连接到具有3.40 GHz Intel Core i7-6700处理器的台式计算机，该处理器具有8 GB RAM，运行Ubuntu 18.04.2 LTS。IOHUB使用现成的设备，具有以下组件：

1）计算部分  使用Raspberry Pi 4（⑥）来实现计算组件，该组件执行所有IOHUB逻辑，包括分析HDMI帧，渲染覆盖层，执行TLS协议等。人们可以使用ASIC进一步提高性能并减少代码库组件的。Pi通过HDMI（⑨）接口连接到显示器。Pi的代码库主要由Python和Java组成。

2）输入拦截器  输入拦截器由Arduino Due（③）和Arduino Zero（④）组成，后者通过USB（②）接口连接到输入设备。输入拦截器具有USB输出接口，该接口连接到主机（⑤），该主机将所有用户输入中继到主机。

3）HDMI拦截器  HDMI拦截器（⑦）使用B101 HDMI转CSI-2桥接器来实现，该桥接器从主机接收HDMI通道（⑧），并将其转换为相机输入信号，再传送到Raspberry Pi 4。

六、总结

    当有攻击者控制的主机存在时，PROTECT IO N提供了一条远程可信路径。解决方案背后的指导原则是：

1）不单独考虑用户输入和输出的完整性；

2）必须同时保护所有的用户输入方式；

3）用户输入完整性保护不应依赖于习惯和易遗忘的用户任务，例如检查安全指标的存在。

    通过遵循这些原则设计了一个新颖的系统，该系统在控制整个主机平台的强大对手的存在下提供强大的用户输入完整性保护。