4.2　设备指纹的技术实现

下面我们来详细介绍设备指纹的实现原理。

4.2.1　Android 设备指纹

设备ID 需要兼具稳定性和唯一性，Android 系统的开源和碎片化导致API 函数实现各不相同，所以兼容性是Android 系统中设备指纹面临的最大挑战。表4.1列举了Android 系统中比较稳定的设备参数。

从统计的系统版本分布图4.1来看，目前国内Android 6以上的手机占比已经超过了85%。由于考虑到用户的隐私，高版本Android 系统增加了设备信息采集的限制。

Android Q 于2019年9月份发布，出于对用户隐私的考虑，Android Q 限制了采集设备标识符，为Android 设备指纹带来了前所未有的挑战。Android Q 禁止非系统应用访问用户不可更改的ID，包括IMEI 号、Serial、USB序列号等。系统Wi-Fi MAC 地址默认是随机生成的，不是固定的MAC 地址，以防止用户隐私被追踪。我们实际测试发现，IMEI、IMSI、Serial、Bluetooth MAC 都已无法获取参数，Wi-Fi MAC 获取不到真实值，但与BSSID 绑定。因此，Android Q 设备指纹的适配，不仅仅是采集函数的兼容，更重要的是设备ID 恢复逻辑（当用户修改手机某些信息时保持设备ID 不变的计算逻辑）的兼容。

从理论上来说，所有的采集项都是Android 系统公开的API，不可能在采集项被大面积篡改的情况下保持设备ID 不变。因此，设备指纹还需要对APP 运行环境进行监测，以识别异常环境。针对Android 作弊环境的检测方法可以归纳为以下5个方面：

· 通过安装包检测安装的作弊工具。

· 通过特定特征识别root 环境。

· 使用多种方案采集同一字段信息。

· 通过通用性的作弊原理识别运行的作弊框架hook（Java/native）。

· 通过特定特征识别运行的作弊工具和模拟器。Android 黑产工具更新速度很快，样式层出不穷，需要通过黑产情报不断搜集最新的作弊方法。

4.2.2　iOS 设备指纹

iOS 相对于开源的Android 而言，权限限制更加严格，手机型号和系统版本相对单一。iOS 能够获取的设备参数比较少，如IDFA、IDFV、DeviceName、MAC。表4.2列举了iOS 系统中比较稳定的设备参数。

从统计的版本分布图4.2可以看出，iOS 13正式版已经于2019年9月推出，因为iOS 系统更新提示频繁，经过三个多月时间，iOS 13占比已经达到49%，超过iOS 12的34%。

大多数iOS 作弊工具都是基于hook 进行改机的，高级的改机工具甚至能够对抗hook 检测。除用于真实设备改机的作弊工具外，市面上还有iOS 模拟器。iOS 模拟器实质上是在x86_64架构上运行iPhone 自带的iOS 模拟器，APP 需要特殊适配才能被安装。

iOS 设备指纹风险识别技术可以归纳为以下6种：

· 通过通用hook 原理识别技术检测运行的作弊工具。

· 通过特定作弊工具特征识别运行的作弊工具。

· 通过特定特征识别越狱环境。

· 寻找特定的空间存储设备标识。

· 对抗hook 改机。

· 对抗备份和抹机。

4.2.3　Web 设备指纹

Web 设备指纹（又被称为浏览器指纹）是由用户设备硬件信息和浏览器配置信息综合计算产生的，它通过JavaScript 脚本采集信息生成对应的设备ID。与传统的cookie 技术相比，Web 设备指纹更加稳定且对抗性更强。Web 设备指纹起源较早，学术界相关的研究论文也有很多，但是工业界能够有效运用在生产上的成熟实现方案较少。2019年，学术界披露的Sensor ID 漏洞曾引起业内的广泛关注。制造商嵌入智能手机固件中的传感器都有系统误差，工厂需要在出厂前对其进行校准来补偿系统误差。这一校准数据具备了很强的唯一性，而且无法被修改，可用于唯一标识设备。但是在实际测试时发现，同一部手机两次获取的偏差值也会有一定概率是不同的。苹果公司已经在iOS 12.2以后的版本中修复了该漏洞，因此该方案也并不具有通用性。表4.3列举了浏览器比较稳定的设备参数。

微信小程序、支付宝小程序设备指纹是某种特殊环境的Web 设备指纹，其运行环境和API 及标准浏览器不同，需要单独定制SDK。小程序设备指纹采集到的字段也会有所增加，在用户授权的情况下可以采集蓝牙信息、Wi-Fi 信息、屏幕亮度、微信/支付宝用户标识等。

由于浏览器能够采集的唯一标识设备的信息非常少，因此Web 设备指纹稳定性比移动端差很多，也比较容易被黑产绕过。常见的黑产作弊方式有普通浏览器隐身模式、无头浏览器、JS 模拟执行等。此外，兼容性也是Web 设备指纹比较大的挑战，尤其是对较低版本浏览器的兼容问题。目前，很多银行还在使用IE8浏览器。新版本浏览器出于用户隐私的考虑，也会增加很多限制，如最新版本的Chrome 浏览器已经默认禁用了内网IP 的采集方法。

Web 设备指纹可以归纳为以下4个方面：

· 识别浏览器端异常环境。

· 通过特定特征识别hook。

· 通过特定特征识别JS 是否被篡改或正在被调试。

· 通过浏览器特殊方式存储设备标识，防止存储的标识被删除。

Web 设备指纹的实现过程主要分为两部分：其一为设备指纹的稳定性，即需要收集较为稳定的设备信息；其二是作弊环境检测，即保证当前Web 设备指纹采集到的信息都是真实的。下面具体说明Web 设备指纹中的一些异常检测原理。

1.无头浏览器的识别

· useragent 检测：/HeadlessChrome/.test（navigator.userAgent）。

· Webdriver 检测：'Webdriver' in navigator。

· Selenium 检测：window._selenium。

· 无头浏览器，如phantomJS、nightmareJS 等不在这里逐一说明。

2.隐身模式检测

· safari 在隐身模式下：localStorage 对象存在，但执行setltem 方法会报异常。

· firefox 在隐身模式下：indexedDB执行open 方法会报异常。

· chrome 在隐身模式下：FileSystem API 禁止，使用会报异常。

3.控制台开启检测

· console.log 隐式调用元素id：（var element = new Image（）； element._defineGetter_ （'id'，function（）{console.log（'控制台已打开'）}）； console.log（element））。

· console.log 隐式调用RegExp 的toString 方法：（var regexp = /./； regexg.toString = function（）{console.log（'控制台已打开'）}）。

4.hook 检测

· 自定义函数hook 检测：在定义函数时将函数整体作为参数生成一个hash 值，在执行函数时进行hash 值的校验。

· 浏览器函数检测：采集调用toString 方法，获取内容进行校验。

· 对象属性检测：对“通过Object.defineProperty 方法更改的属性，是不可更改的”这一特性进行检测。前后两次调用Object.defineProperty 方法，第一次正常，第二次会报错。如果不符合预期，则说明被hook。

4.2.4　设备ID 生成与恢复逻辑

设备指纹SDK 采集终端设备信息完成后，会计算生成一个唯一ID 来标识设备，如图4.3所示为设备ID 生成逻辑示意图，需要注意的是，设备ID 是在后端生成的。从前端的角度考虑，无论采用多强的加固和混淆，都能够逆向还原代码。如果由前端生成设备ID，那么只要逆向出相关逻辑就能批量生成合法的设备ID。同理，如果将设备ID 直接返回前端，在前端做风控策略，就很容易被绕过。此外，特征与设备ID 的关系是多对一的映射，特征会碰撞但设备ID 必须满足唯一。

设备ID 恢复逻辑，就是从采集到的设备信息中筛选特征组合。如果新采集的设备特征与数据库中已有的设备特征相同或相似，就认为新采集的设备是同一台设备，赋予相同的设备ID。如果没有查找到相似的设备，就认为是一台新设备，生成新的设备ID。恢复逻辑需要权衡稳定性和唯一性。唯一性和稳定性是一个权衡的过程，一个高另外一个就低。稳定性表示设备经过改机或恢复出厂设置以后还能保证设备ID 不变。唯一性表示不同设备，尤其是同一型号的设备ID 不一致。如图4.4所示为设备ID 恢复逻辑示意图。

目前，SaaS 服务已有数十亿台设备，设备ID 恢复逻辑会优先保证唯一性，即在保证唯一性的前提下保证稳定性。从恢复逻辑的定义可以看出，即使同样的算法逻辑，SaaS 设备指纹和企业级私有化部署的设备指纹生成的设备ID 也是不一致，原因是存储不互通。SaaS 是指数据直接传到云端服务器，由云端设备指纹后台服务生成设备ID；企业级是指数据传到客户服务器，由部署在客户服务器上的设备指纹后台服务生成设备ID。

如何设计一套好的设备恢复逻辑呢？这个问题没有最好的答案。如果希望稳定性高，那么可以采用单一设备参数进行恢复，大部分厂商都是采用的这种方案；如果希望唯一性强，那么可以采用多个设备参数进行恢复。恢复逻辑是否合理，需要依赖海量数据的积累和验证。例如，华为的某款手机，Wi-Fi MAC 和Serial 都一样，采用单一设备参数做恢复就会导致设备ID 大量碰撞。在大多数情况下，厂商招标时的POC 测试只关注稳定性而忽略了唯一性。如果想要测试设备ID 唯一性，那么必须依赖上线以后的大规模测试。一个设备指纹厂商只有企业级私有化部署形态的产品，没有SaaS 形态的产品和服务，这就难以把设备ID 做好。更高级一点的设备ID 恢复，可以使用设备特征相似算法生成设备ID。这种技术方案主要面临以下几种挑战：

· 海量数据的高性能检索。

· 相似度权重如何选取。

· 每个参数根据特点挑选不同的相似算法。

· 两个设备判定是否相似的阈值如何设定，同一型号设备相似度很高容易碰撞。

实际测试的效果，相似算法比传统算法更加灵活，而且在保证唯一性的前提下稳定性更好。

无论何种恢复逻辑，都无法对抗修改大部分设备信息的情况。再强大的设备ID 在高级的改机工具面前，也是无法做到稳定恢复的。关于设备ID 跨浏览器及APP 跨浏览器，从业务角度分析该需求具有一定合理，从技术角度上判断是一个伪命题。受到浏览器的限制，JS 本身能采集到的信息非常有限。想要做到跨浏览器（稳定性好），就可能会导致设备ID 的大量碰撞（唯一性差）。在大规模使用的情况下，跨浏览器ID无法直接用于策略。

4.2.5　被动式识别技术

在设备指纹中会应用一些被动式识别技术，行业称为被动式设备指纹。这种设备指纹是指在终端设备与后台服务器建立连接的过程中，从网络报文中提取多个维度的特征集，在后台使用机器学习算法识别终端设备。这类被动式的设备指纹，在没有完全流量的情况下，仅利用建立连接的过程数据是很难生成一个唯一设备ID 的，但是可以用于设备验真（验证设备参数是否真实，未被篡改）。

在实战中，通过IP 及TCP 头部中的一些字段可以做到操作系统类型检测、特定类型模拟器识别及网络状态的探测等；在应用层使用SSL/TLS协议指纹，可以做到虚假浏览器识别、客户端设备类型和恶意工具识别等。图4.5列出了不同类型操作系统的协议特征差别，供读者参考。

被动式设备指纹能够获取的特征比较少，虽然攻击者不易伪造特征，但是唯一性较差。因此，主被动式结合是设备指纹的一种可尝试的思路。 mtF8zjpa8xB4cqKVRYOel4iVHTKo6XdU0qrHVTj9iblfqHW6Tfixf6nyNIHU2p3y