在本文中我们将证明，在现今许多手机模型上都有的hover（floating
touch，悬浮触控）技术可以被恶意软件滥用，用来记录系统范围内的所有触屏输入。通过这种攻击，运行在Android系统上的恶意软件可以获取用户的敏感信息诸如密码、PIN，记录用户的社交，掌握用户的行为。为评估此类攻击，我们实现了一款POC（proof-of-concept，概念验证）恶意软件Hoover，让它在后台运行并记录下前台应用程序的输入。
与现在广为人知的边信道攻击（side channel attack）不同，本文是第一篇证明了hover技术的安全隐患以及它盗取用户输入的潜在可能性。我们也讨论了减轻此类攻击的方法，并发现不能通过简单的限制权限或者提高用户意识来实现，因为这将大大缩减hover技术的使用率。
近年来输入推理攻击（input inference attack）迅速发展，此类攻击是指盗取用户部分或全部输入。这并不足为奇，因为此类攻击可以让人对用户有大概的了解，或者获取用户的敏感信息诸如登录信息、信用卡卡号、私人信件等等。
现有的攻击主要是应用程序层面的，通过phishing（钓鱼）或界面伪装（UI redressing）诱使用户输入敏感信息。其他攻击利用手机上的传感器作为边信道，通过读取不同传感器，例如加速器、回转仪和麦克风，推断用户输入。在Android上，读取这些传感器（麦克风除外）的信息并不需要特殊的权限。
本文我们介绍一种新的基于Android设备的输入推理攻击，比起前人的工作，我们这个攻击准确率更高、更通用。我们的攻击同时影响设备上运行的所有应用程序（它是系统范围内的），而且它并不是专门为哪一款应用程序定制。它可以持续以高准确率收集用户输入，而且对环境条件不敏感。之前的方法要么针对特定的输入类型（比如，数字键）是应用程序级别的，是粗粒度的，要么是只在特定条件下有效（有限的手机移动，明确的手机位置，有限的环境噪声）。我们的攻击不是基于软件漏洞或者系统错误配置，而是基于新的未预料到的对新兴的hover技术的使用。
自从Samsung—手机市场的一大巨头，将hover技术应用到Galaxy S4,S5和Note系列以后，hover技术方才流行起来。因此本文所提到的攻击会影响到数以万计的用户。Hover技术，如图1所示，会引发一种特别的事件（hover event，hover事件），此类事件可以让用户在没有物理接触屏幕的情况下与设备进行交互。我们将展示如何利用此类hover
event进行强有力的，系统范围内的输入推理攻击。
图1：Hover技术。输入设备在没有接触到设备屏幕的情况下引发特殊的事件（hover event）。最右图展示了用户在输入设备没有接触到屏幕的情况下与手机进行交互。
为获取足够的post-tap（点击后）hover event以便正确推断精确点击坐标，在用户对前台app进行每一次点击后，我们的攻击方式是立刻谨慎地创建（create）和销毁（destroy）覆盖窗口（overlay windows）。先前的phishing、clickjacking和UI
redressing技术也创建覆盖窗口，但是都得用到SYSTEM_ALERT_WINDOW权限。我们的攻击方式并不依赖于该权限：我们的攻击不需要任何权限。而且，我们利用覆盖窗口的方式也不一样。我们的攻击是持续的，对用户完全透明，不会影响用户与前台app的交互，也不会将用户重定向到其他的恶意view上，更不会以任何方式欺骗用户——此前的攻击都做不到这点。
为评估此类攻击，我们实现了一款POC（proof-of-concept，概念验证）恶意软件Hoover，让它在后台持续运行并记录下前台应用程序的hover输入。但是，要实现我们的攻击我们还得克服一些技术挑战。我们最初的实验表明hover技术，很令人意外，并不直接获取用户点击的位置。相对的，hover事件散落在更广阔的区域。因此，为成功预测输入事件坐标，我们首先要知道用户是如何与手机进行交互的。为达到此目的，我们进行了一个用户实验，让20个志愿者用安装了hoover的设备进行两项操作：随便在屏幕上点、输入英文。Hoover收集到的hover
event将用来训练回归模型以预测点击位置和用来生成一个推断输入键位的分类器。
事实证明，我们的攻击对触控笔和手指输入均有效。而且手指点击的误差为100px，触控笔误差只有2px。而在键盘输入事件中，触控笔和手指的键盘键位推断的正确率分别为98%和79%。
我们的这种攻击最直观的应用就是获取用户的输入信息，并且是系统范围内的。比如说，Hoover可以记录敏感输入，例如pin，密码还有社交信息（信息类app，邮件）。当然还有其它更微妙的应用。比如，Hoover可以刻画用户与设备的交互方式，也就是形成用户的生物计量学简介。这份简介又可以用来，比如说，仅对设备主人的限制访问，或者帮助敌手绕过现有的基于生物认证技术的按键[20]。
针对我们的攻击，我们讨论了应对策略，发现要么不能对抗此类攻击，要么将影响系统或hover技术的使用。
最后，本文有如下贡献：
我们介绍了一种全新的、系统范围内的基于hover技术的Android用户输入推断攻击。
我们实现了用户测试，证明了Hoove的正确性。
我们讨论了可能的应对策略，发现此类攻击很难抵御。
本文后面的组织如下：第二部分我们介绍有关hover技术的相关概念和Android系统的view的UI组件。第三部分，描述本文要考虑的问题以及我们的攻击。接下来，第四部分是Hoover的实现和评估。攻击实现是在第五部分，在第六部分我们讨论可能的抵御策略。第七部分回顾在本领域的相关工作，第八部分总结并展望未来。
Hover（或者floating touch，悬浮触屏）技术可以让用户在不物理接触屏幕的情况下与移动设备进行交互。我们在图1已经展示过这个概念了。该技术于2012年由Sony Xperia Device[32]引入，基于结合互电容和自电容感知。被Sony引入后，在2013年11月下旬，hover技术被Asus用到它的Fonepad Note
6中。最终兴起是在Samsung，手机市场一大巨头，将它用到Galaxy S4,S5和GalaxyNote系列。单单是Samsung就出售了超过1亿台支持hover技术的设备[5,6,11,15]——它们都是本文所提到的攻击的潜在目标。
Hover是这么处理的：当用户与屏幕交互时，系统可以在未触摸到它的时候就检测到输入设备的位置。尤其是，当输入设备徘徊在屏幕周围20mm的时候（见图1），操作系统会在规定区域触发一类特殊的用户输入事件——hover
event。App以x,y坐标的形式获取输入设备的精确位置。只要获取了输入设备的位置，位置将被发送到View——Android用户接口内置模块——以监听事件。更具体点，就是当用户徘徊在屏幕上方并点击屏幕后，操作系统产生的事件流是这样的：当输入设备接近屏幕（小于20mm）,系统就针对（x,y）坐标发起一系列hover
event。当触摸到屏幕的时候，hover退出事件（hover exit event）就紧随着按下事件（touch down event）触发。Touch up事件意味着触摸完成。之后，当用户将输入设备带离触摸点的时候其他一系列的hover event会再次触发。最后，当输入设备离开悬浮区域，也就是说，距离屏幕的悬浮高度大于20mm，就产生hover exit event。
Android通过WindowManager处理系统可视化和屏幕上的app UI控件。它的工作主要是管理和生成window、view、button、image和在屏幕上出现的其他对象。基于攻击的目的，可以产生不同的view（主动view，例如button；或被动view，例如image）以获取hover
event和触摸事件。View的模式是可以改变的，通过设置或不设置特定的标志，可以化被动为主动。这些标志可以通过WindowManager接口的updateViewLayout()
event。通过设置这两个标志，静态view就不会影响设备的正常使用，即使是它在其他window的上面。另外，通过设置某个view的FLAG_WATCH_OUTSIDE_TOUCH，当屏幕上某处，并且在该view的外面发生点击事件，无需知道点击的位置，也能精确获取该view。
在本文中，我们将会用到在其他对象，包括前台app的view顶层的view。这些view要么是Alert
Window，WindowManager接口需SYSTEM_ALERT_WINDOW权限，这部分由产生该view的service完成。但是，用Toast类的话，实现我们的攻击所需要的功能不用任何权限。但是因为Toast Window的技术更难处理，此类实现比较复杂。因此，我们先用Alert Window实现我们的攻击，稍后在4.6节再解释如何不需要特殊权限实现攻击。
我们攻击的目标是以高精确率（比如，低误差）和高粒度（比如，在按键键位级别）追踪用户的每一次点击。只要用户与之交互的设备支持hover，那么不管输入设备是手指还是触控笔，攻击都有效。而且，攻击不应该被用户察觉，也就是说，攻击不会以任何形式影响用户与设备的交互。
在描述攻击之前，我们先声明假设和敌手模式。
3.1 假设和敌手模式
我们假设用户运行的手机支持hover技术。用户用触控笔或手指与设备交互都没有关系。
我们假设的情节是，攻击者控制着在用户设备上运行的一款恶意软件。目标就是，在不被用户发现的前提下获取用户输入信息。在我们第一个攻击，更容易实现的攻击中，该恶意软件只需要两个权限：SYSTEM_ALERT_WINDOW，就如前文所说的，这个权限在很多app中都有，和INETERNET——这个就更常用了，以至于Android将它的保护级别设置位PROTECTION_NORMAL。也就意味着这是无害的，而且所有app都有这两个权限，不需要询问用户。然后我们再讨论不需要SYSTEM_ALERT_WINDOW权限的攻击，这个攻击更复杂些。
为追踪输入设备的点击，我们探索Android操作系统发送hover事件到app的方式。当用户点击屏幕的时候，会以坐标和时间戳的形式形成一系列事件：hover（输入设备悬浮）；hover
为观察这些事件，如果该恶意软件有SYSTEM_ALERT_WINDOW权限的话，它可以生成一个透明的AlertWindow覆盖在上面，不然它也可以如4.6节描述的那样用Toast类覆盖实现攻击。注意到在Android系统中，Alert Window是在其他view的上面的（见第二部分）。一旦创建，该覆盖窗口可以获取点击所触发的一系列hover
event，如此便可追踪输入设备。以秘密方式做到这些不惊扰用户与app的交互并非微不足道。因为，Android只把hover event发送给收到touch event的view。而且，系统先知touch stream（触摸流）的消耗，所有事件，包括touch
down和touch up仅针对一个view。所以，用来追踪输入设备的恶意软件要么可以截取hover
event和触摸事件，那这样就影响对实际app的触摸，要么就是截取不到，那这样就无法推断用户输入。
由敌手控制的恶意软件不能直接并隐秘的观察点击事件。但是我们可以证明通过观察用户点击之前和之后的hover事件可以隐秘地推断点击。要正确达到此目的，敌手需在不影响用户交互的情况下推断用户输入。
更具体一些，我们的攻击是这么实现的：恶意软件生成一个完全透明的Alert
Window覆盖在整个屏幕上。该覆盖窗口位于其他窗口之上，包括用户正在用的app。因此，恶意软件可以追踪hover event。但是恶意view要及时以一种“聪明的方式”化主动（抓取所有事件）为被动（让它们顺利到达下层app）。恶意软件通过WindowManager API，可以在影响用户交互的情况下适时的创建和移除覆盖窗口。
敌手（恶意软件）是一直运行在受害者设备上的后台服务。之前说过，它的难点在于如何知道将覆盖窗口由主动（将它放到屏幕上）变为被动（将它移除）然后再次变成主动的确切时间。须注意，为保证隐密性，我们只抓取hover
event，并不抓取用户与之交互的app的触摸事件。因此，预测用户何时停止悬浮输入设备进行点击并不简单。我们通过如下方法进行处理：通过WindowManager，恶意软件其实是利用了2个view。一个是之前提到的完全透明的Alert
Window。第二个，我们称之为监听器，其大小为0px，既不抓取悬浮坐标也不抓取点击事件。它存在的意义仅仅是告诉恶意软件何时发生了点击事件。然后恶意软件Hoover将利用这条信息移除/重建透明覆盖窗口。
3.4.1 推断点击时间。
所有用户点击都发生在监听器外面——它的大小是0px。另外，这个view设置了FLAG_WATCH_OUTSIDE_TOUCH，所以当由点击事件引起的touch
down event发生是它会收到通知。结果就是，恶意软件可以推断点击的时间戳，虽然它不知道点击位置（见图2步骤1）。
为了推断点击位置，攻击者在touch down
event触发后马上激活透明覆盖窗口，点击事件将顺利传送给真正的app。（见图2步骤2）。这就保证了攻击不会影响到正常的设备使用。而覆盖窗口，从此刻起，拦截输入设备从点击位置到下一次点击位置所引起hover
与监听器的那个view不一样，监听器不会拦截用户的交互，因为它只有0px，覆盖窗口不能一直是活动的（出现在屏幕上）。不然它会干扰用户的下一次输入。同时，覆盖窗口又必须活跃足够长的时间，以保证能抓取足够多的hover event来推断点击位置。我们的实验表明，用本文所说的设备，系统平均每19ms产生一次hover event。我们还发现，70ms的活跃事件足够获取足够多的hover
event去推断点击而不影响用户交互。这70ms包括了app的使用时间，不是点击时间，是像在键盘上输入时提示输入键位的那部分时间。当活跃时间用完，覆盖窗口将再次被移除（见图2步骤4）。
图3：Hoover收集hover event。用触控笔输入时，hover event（h,h,……,h）紧紧跟随触控笔的路径，用手指的话它们就散落在更宽一点的区域。
在这一部分，恶意软件已经收集了用户点击所引起的一系列post-click
hover event。利用收集到的信息，攻击者的目标是推断用户点击的具体位置。一个方案是只用第一次点击所引起的hover
event确定点击位置。但是这个方案虽然对触控笔效果很好，对手指的结果却不太好。原因就是，触控笔的接触面比较下，形成的hover
event都仅仅跟随用户的移动（见图3）。所以，第一个post-click hover event（相对的是，点击之前的最后一个hover event）跟事实的点击位置很接近。相反的，手指的接触面比较大，所以hover event，包括那个点击后的，也不如触控笔那样紧密的贴近用户移动轨迹。这在我们最初的实验中就已经证实。该实验结果表明，第一个post-click hover
event所抓取的位置很少在点击位置的上方。
出于此，为提高推断点击位置的正确率，我们决定应用机器学习工具，它不单考虑第一个post-click hover event，而是考虑了70ms内所抓取的全部事件。尤其是，为了一般化输入推断攻击我们应用了回归模型。对于有关键盘的攻击（键位推断）我们利用分类器。在高层次上，给定一系列post-click hover
event（h,h,……,h），回归模型要回答以下问题：“用户点击的位置在哪里？”同样的，分类器输出最可能是用户输入的那个键位。为评估攻击，我们用了数个回归模型和分类器，这些模型和分类器用的是scikit-learn[25]框架。我们在下一部分的结果中进行描述。
在我们最初的实验中，我们注意到不同的用户有不同的hover event模式。有些用户移动输入设备的速度比较快。就手指而言，手指的形状和大小所产生的hover模式是不一样的。为保证点击预测的正确率和鲁棒性，我们需要用不同的用户所产生的数据训练回归模型和分类器。出于此，我们进行了两类用户实验，将在下一部分进行描述。
4.1 攻击原型（恶意软件）和实验安排
为评估本文所说的攻击，我们针对Android系统设计了一款恶意软件原型，叫Hoover。这个原型按逻辑分为两步：首先收集hoverevent（如第三部分说的）然后分析它们以预测用户的点击坐标。我们用两个不同的组件来实现这两步。这两个组件可以在用户设备上同时运行。但是因为功能不同，为了方便分析，我们将它们分开了。Hover
event收集组件是在用户设备上运行的Android恶意app。分析器用python实现，运行在远程服务器。它们之间的通信通过恶意软件的INETERNET权限来实现，INETRNET权限是普通权限，所有Android app均默认配置，不会惊扰用户。
上传收集到的hover event到远程服务器并不需要多大的带宽。举个例子，一台设备运行四个小时，恶意软件收集到近3800次用户点击所引起的hover event。加密后每次点击的hover event是40 Byte，总的就150KB。这样的数据还是大量使用的结果，我们是为了得到一个上界才进行的。所以，我们相信，在实际生活中，一般用户点击产生的数据量会非常小。
最后，为进行实验，我们招募了20名志愿者，他们的数据在在下一节中。评估Hoover分两个场景：一个场景是用户在屏幕上乱点，另一个是明确的点击键盘输入文字。我们用两种不同的输入设备和表一所展示两种不同的设备进行了大量的实验。但是，Hoover所表现的想法是通用的，不依赖于某个设备。因此，我们相信，此类攻击对于其他支持hover技术的Android设备一样有效。
4.2 用例和志愿者招募
在这一节我们描述用例的具体细节，同时报告为评估攻击所做的志愿者招募。
用例Ⅰ（常规点击）这个用例的目的是收集用户随意在屏幕点击的信息。因此，我们让志愿者玩一个定制游戏：时不时的点击随机出现在屏幕上的小球。这个用例持续2分钟。
用例Ⅱ（文本输入）这第二个用例主要是键盘输入。志愿者被要求输入乔治奥威尔的《1984》的一段文章。每一段，平均有250个英文字母，包括标点符号。
每个用例由志愿者进行3次。第一次用拇指作为输入设备，第二次用食指，第三次用触控笔。我们记录下实验中所有用户点击位置和hover event。
研究的第一方面是Hoover在不干扰用户下一次点击的情况下覆盖窗口能保持活跃多久。实验表明，在98%的例子用，点击与点击之间的间隔大于180ms。
hover event的数目是如何影响预测的准确率的。出于此，我们让两个志愿者进行一个初步实验研究。最初的实验结果表明正确率随着hover
event的数目成比例增长。但是，在前4个event之后，正确率的增长小于1%（4个事件正确率为78%，5个为79%）因此，要评估Hoover原型，我们只需用4个post-click
event总是在用户点击后70ms内发生。
最后，注意到相对于我们实验观察到的180ms的点击间隔，我们选择70ms略微保守。但是，如我们在下一节看到的，预测结果的正确率还是很高的。一方面，长时间的收集能增加post-hover
event的数量提高恶意软件推断用户输入的正确率。另一方面，当用户点击的速度非常快——比我们实验的用户更快的时候，静态的、长时间的收集会暴露敌手身份。也就是说，更成熟的敌手应该可以开起任意短时间收集窗口并动态适应用户的输入速度。
在这一节我们给出有关Hoover推断用户点击坐标的有效性和准确性的实验结果。一旦Hoover手机到用户的post-click hover event就将他们发送给基于机器学习的运行在运行服务器上的分析器。
4.4.1 推断用户常规点击的坐标。
分析器应用回归模型推断用户在屏幕上的点击位置。直观上，正确率取决于预测使用的模型。因此，我们用了几个模型来做实验。包括两个线性模型（Lasso和线性回归），一个决策树，和一个集成方法（随机森林）[25]。每个模型的输入都是Hoover（见第三部分）对每一个用户每一次点击收集到的post-click
cross-validation）,也就是说，样本里的所有对象（用户点击）都经历测试和验证。根据对20位志愿者进行实验得到的数据，我们的预测结果如图4（a）和4（b）所示，分别为触控笔和手指。我们可以看到不同的回归模型的均方根误差（Root Mean Square Error,RMSE）是不一样的。
首先，我们观察到，对于所有的回归模型，手指的正确率均低于触控笔的正确率。这是预料之内的，因为针对触控笔的hover检测技术的正确率就比较高（hover
event紧随着其移动），手指的话，hover event散落在更宽的范围。虽然如此，两者的预测也都很不错。尤其是，触控笔的预测误差（estimation error）仅为2px。还要记住，实验所用的最小的设备是Note 3 Neo，其大小是720*1280px.
最后，我们注意到，对于触控笔（见图4（a））,简单线性回归模型比其他复杂模型的效果更好。但是对于手指（见图4（b））就不是这样。实际上，对于手指来说，预测效果最好的是随机森林模型，其次才是线性模型。我们相信，这依然是因为触控笔抓取到的hover
event比较精确，相对于手指来说。
为在基于键盘的用例中的用户输入键盘推断，我们应用如下方法：（1）用先前的方法论推断对应的点击坐标，（2）观察预测好的点击坐标坐落于那些键位区域，（3）输出预测的键位。
就像之前所说的，对于用线性回归模型进行的触控笔点击预测，其正确率非常高——与真实点击坐标仅有2px的误差。所以，上面的方法对触控笔来说不是问题。但是，对手指的话就不那么使用了，因为误差太大。因此，我们用了另外一种方法，并针对后面的分类提出了一个问题：“根据观察到的post-click
hover event，用户按了哪个键？”。同样的，我们应用了几个分类模型：两个基于树（决策树和extra tree），Bagging分类器和随机森林方法[25]。和回归问题一样，我们得用一个基线（baseline）模型作为基准（benchmark）。基线是将第一个post-click
关于用例Ⅱ文本输入的推断结果如图4（c）和4（d）所示，分别为触控笔和手指。首先，我们观察到，对于两种输入方法在键位预测上随机森林模型（Random
Forest，RF）的正确率是最高的——手指的是78%（见图4（d））,触控笔的是98%（见图4（c））。值得一提的是，对于手指，baseline和随机森林模型的结果差距有点大——baseline是40%，随机数是79%。但是触控笔的就和正确结果都差不多。尤其是，baseline和表现最好的随机森林模型仅相差1%,
随机森林的是98%（见图4（c））。
这些结果表明，Hoover可以正确偷取用户在屏幕键盘上的输入。而且，我们相信，在应用更复杂的基于字典的纠正后正确率会有所提升。
4.5 从其它点击中区分键盘输入
Hoover收集所有类型的用户点击。所以，需要区分屏幕键盘点击和其他类型点击。一种方法是利用边信道，例如，/proc文件夹。Hoover可以用和文献[8]类似的技术获取用户输入。但是出于两个原因，我们不能单单用/proc文件实现键盘检测。第一，它不是完全正确的[8]，有一定的假阳（false positive）和假阴（false
negative）。第二，我们不能确定/proc文件夹总是可用的，且所有app都可以接触到它。
因此，我们应用一个简单的启发式方法来解决这个问题。这个方法利用屏幕键盘位于设备屏幕底端这一事实。因此，当用户进行输入时，点击更倾向于键盘所在区域。最简单的方法是应用一个estimator（评估者）从所有用户点击中区分目标键盘键位。这个方法不会出现假阴。但是会出现假阳。实际上，用户有很多可能会在屏幕下方进行点击：在需要点击的游戏，有些游戏的开始键就在这个区域，等等。
为过滤会引起假阳性的点击，我们进一步改进我们的方法。想法很简单：如果用户真的是文本输入，她需要在屏幕下方进行大量连续点击。所以我们过滤掉短点击序列（少于4个字母），这甚至不可能是用户名或密码。而且，根据经验，在用户打开输入框开始进行输入，起码有500ms的时间间隔她才会敲击第一个键。这个时间是将键盘加载到屏幕上所花费的。我们把这个条件添加到启发式方法中以减少假阳性。
为评估这个启发式方法，我们收集了一台手机在48个小时正常使用下（例如，聊天，浏览网页，打电话）的数据。我们收集当用户开始（和结束）与键盘交互的点击事件，hover
event，时间戳。这两个启发式方法的假阴性均为0。简单版本的假阳性为14.1%，改进版本的下降到10.76%（提升了24%）。
这两个启发式方法仅仅是概念验证（proof-of-concept）。我们相信，包含输入时间与点击触摸时间（也就是用户把输入设备放在屏幕上的时间）差别的更成熟的改进方法能够减少假阳性。但这超出本文范围。
至今为止，我们所说的Hoover是通过Alert Window实现的，需要SYSTEM_ALERT_WINDOW权限。现在，我们证明我们可以不用该权限就实现同样的功能，用一种更复杂的方法：利用Toast类[2]。
Toast类用来生成通知或者关于系统的快速消息（quick message）。关于Toast的一个例子就是当用户提高或降低音量时出现的音量控制器窗口。他们不需要任何特殊权限而且可以为任意服务或用户app所用。更重要的是，和Alert Window一样，Toast可以抓取hover
event，能包含定制的View类对象，而且总是在其他窗口的上面，包括前台app。因此，监听器和透明覆盖窗口都可以由Toast Window生成。
作为概念验证，我们用Toast
Window实现了Hoover的一个版本。Android限制Toast的活跃时间仅为几秒。所以要实现监听器就比较困难，因为监听器应该一直在屏幕上。实际上，利用Toast类，Hoover可以在监听器消失之前定期地调用toast.show()。透明覆盖窗口不存在这个问题，因为在之前的章节中我们已经验证过，在监听器检测到点击事件后透明窗口只需出现70ms。收集到hover
event以后移除覆盖窗口激活监听器。通过此种方法我们可以让Hoover实现同样的功能而不需任何其他权限。
4.7 进一步实现攻击
先前的论述证明hover event可以用来正确推断用户输入，包括常规点击位置和键盘键位。
在这一部分，我们给出两种技术，我们相信，可以提高攻击和正确率。
语言模式。在评估中我们考虑的是最复杂的情况，也就是没有假设输入文本的语言。尽管实验中志愿者们用的是英文，但是对其他任何语言同样适用。更老练的攻击者应该首先检测用户输入的语言，然后在用我们描述的方法进行键位推断，应用误差修正算法提高正确率。
Per-user模型。在评估中，不管是回归模型还是分类器，我们都是由所有用户实验所得的数据进行训练。也就是说，得到的回归和分类模型之后也用来评估所有用户。这个模式的有点是，如果攻击新用户，攻击结果和我们实验所得结果差不多。但是，我们也可以想一个per-user
模型提高准确率。我们无法用我们的数据库验证这个想法，因为我们没有足够多的per-user数据。但是，我们对两个有最多数据点的用户进行了初步评估。结果显示per-user模型能改进，尤其是针对手指。实际上，就键盘推测正确率，第一个用户从79%（所有用户的数据）提升到了83%，第二个则是86%。
4.8 另一种键盘输入方法
针对文本输入，我们的攻击非常有效且正确。但是对于滑动输入文本（swiping
text）就不是那么有效了。实际上，Hoover只在输入设备离开屏幕时推断坐标。用swiping，仅能推断用户划过的每一个单词的最后一个字母。但是，也需注意到，对于类似密码的文本以及数字或符号，swiping是无效的，须用户输入。因此，就算是有swiping，Hoover依然能窃取用户的敏感信息，诸如密码或pin码。
在攻击中，我们假设用户使用的是常规键盘。但是，用户也可能应用其他复杂的安全机制，例如定制键盘，在输入敏感信息后重新布置键位。这种输入机制当然能减轻我们的攻击：这样Hoover无法将坐标与键位联系起来。但是当用户发现在那种每次输入后都重置键位的键盘上书写特别痛苦的时候，这种设备的使用率也会下降。最后，这种机制会倾向于保护类似PIN和证书类敏感信息，而短信、email和其他信息序列依然暴露在我们的攻击之下。
转载请注明来自看雪社区
特别声明：本文为网易自媒体平台“网易号”作者上传并发布，仅代表该作者观点。网易仅提供信息发布平台。
