第３４卷第１１期 ２０１７年ｌ１月 计算机应用与软件 Ｃｏｍｐｕｔｅｒ Ａｐｐｌｉｃａｔｉｏｎｓ ａｎｄ Ｓｏｆｔｗａｒｅ Ｖｏ１．３４ Ｎｏ．１ １ ＮＯＶ．２０１７ ＴＬＳ１．３协议更新发展及其攻击与防御研究 沈若愚 卢盛祺 赵运磊 （复旦大学软件学院上海２０１２０３） （上海财经大学信息管理与工程学院上海２００４３３） 摘要 ＳＳＬ／ＴＬＳ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ／Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）协议旨在为网络通信提供安全的信道，为通 信双方提供认证、机密性和完整性。由于协议的复杂及其设计和实现上的漏洞导致许多安全隐患，新版本ＴＬＳ １．３的制定引起信息安全学术界和产业界广泛的关注。概述ＴＬＳ１．３的协议结构。在此基础上，对ＴＬＳ１．３几个革 新性的改变：密钥编排表、ＰＳＫ和０－ＲＴｒ进行了系统性地分析与梳理。对近１Ｏ年协议受到的攻击按照协议的层 次分类进行概述，提炼出每种攻击的原理以及ＴＬＳ１．３针对这些攻击作出的应对措施。对ＴＬＳ协议的未来发展作 出预测并提出建议。 关键词中图分类号ＴＬＳ１．３ ＳＳＬ／ＴＬＳ攻击ＴＰ３ ０－ＲＴＴ ＰＳＫ 密钥生成表 Ａ ＤＯ１：１０．３９６９／ｊ．ｉｓｓｎ．１０００—３８６ｘ．２０１７．１ １．０４９ 文献标识码ＴＨＥ ＤＥＶＥＬｏＰＭＥＮＴＳ ｏＦ ＴＬＳ１－３ ＡＮＤ ＩＴＳ ＡＴＴＡＣＫ ＡＮＤ ＤＥＦＥＮＳＥ Ｓｈｅｎ Ｒｕｏｙｕ Ｌｕ Ｓｈｅｎｇｑｉ Ｚｈａｏ Ｙｕｎｌｅｉ （Ｓｃｈｏｏｌ ０厂Ｓｏｆｔｗａｒｅ，Ｆｕｄａｎ Ｕｎｉｖｅｒｓｉｔｙ，Ｓｈａｎｇｈａｉ ２０１２０３，Ｃｈｉｎａ） （Ｓｃｈｏｏｌ Ｄ，Ｉｎｆｏｒｍａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｅｎｇｉｎｅｅｒｉｎｇ，Ｓｈａｎｇｈａｉ Ｕｎｉｖｅｒｓｉｔｙ Ｆｉｎａｃｅ ａｎｄ Ｅｃｏｎｏｍｉｃｓ，Ｓｈａｎｇｈａｉ ２００４３３，Ｃｈｉｎａ） Ａｂｓｔｒａｃｔ Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ／Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＳＳＬ／ＴＬＳ）ｉｓ ｉｎｔｅｎｄｅｄ ｔｏ ｐｒｏｖｉｄｅ ａ ｓｅｃｕｒｅ ｃｈａｎｎｅｌ ｆｏｒ ｎｅｔｗｏｒｋ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，ｐｒｏｖｉｄｉｎｇ ａｕｔｈｅｎｔｉｃａｔｉｏｎ，ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ ａｎｄ ｉｎｔｅｇｒｉｔｙ．Ｄｕｅ ｔｏ ｔｈｅ ｃｏｍｐｌｅｘｉｔｙ ａｎｄ ｌｏｏｐｈｏｌｅｓ ｉｎ ｔｈｅ ｄｅｓｉｇｎ ａｎｄ ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｆ ｐｒｏｔｏｃｏｌ ｌｅａｄｉｎｇ ｔｏ ｍａｎｙ ｓｅｃｕｒｉｔｙ ｒｉｓｋｓ，ｔｈｅ ｄｅｖｅｌｏｐｍｅｎｔ ｏｆ ｔｈｅ ｎｅｗ ｖｅｒｓｉｏｎ ｏｆ ＴＬＳ１．３ ｃａｕｓｅｄ ｗｉｄｅｓｐｒｅａｄ ｃｏｎｃｅｒｎ ｉｎ ｔｈｅ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｃｕｒｉｔｙ ａｃａｄｅｍｉａ ａｎｄ ｉｎｄｕｓｔｒｙ．Ｗｅ ｏｕｔｌｉｎｅｄ ｔｈｅ ｐｒｏｔｏｃｏｌ ｓｔｒｕｃｔｕｒｅ ｏｆ ＴＬＳ１．３．Ｏｎ ｔｈｉｓ ｂａｓｉｓ，ｓｅｖｅｒａｌ ｉｎｎｏｖａｔｉｖｅ ｃｈａｎｇｅｓ ｏｆ ＴＬＳ１．３ ｗｅｒｅ ｓｙｓｔｅｍａｔｉｃａｌｌｙ ａｎａｌｙｓｅｄ ａｎｄ ｃｏｍｂｅｄ，ｓｕｃｈ ａｓ ｋｅｙ ｓｃｈｅｄｕｌｅ．ＰＳＫ ａｎｄ ０一Ｒ ＩＹＩ、．Ｗｅ ｒｅｖｉｅｗｅｄ ｔｈｅ ａｔｔａｃｋｓ ｒｅｃｅｉｖｅｄ ｂｙ ｔｈｅ ｐｒｏｔｏｃｏｌｓ ｆｏｒ ｔｈｅ ｌａｓｔ １０ ｙｅａｒｓ，ａｎｄ ｅｘｔｒａｃｔｅｄ ｔｈｅ ｐｒｉｎｃｉｐｌｅ ｏｆ ｅａｃｈ ａｔｔａｃｋ ａｎｄ ＴＬＳ１．３ ｒｅｓｐｏｎｓｅ ｔｏ ｔｈｅｓｅ ａｔｔａｃｋｓ．Ａｎｄ ｗｅ ｍａｄｅ ｓｏｍｅ ｐｒｅｄｉｃｔｉｏｎｓ ａｂｏｕｔ ｔｈｅ ｆｕｔｕｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｏｆ ＴＬＳ ａｎｄ ｍａｋｅ ｓｏｍｅ ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ． Ｋｅｙｗｏｒｄｓ ＴＬＳ１．３ ＳＳＬ／ＴＬＳ ａｔｔａｃｋ ０．ＲＴＦ ＰＳＫ Ｋｅｙ ｓｃｈｅｄｕｌｅ 展、变体、工作模式、参数算法协商复杂多变。 ０ 引 言 ＳＳＬ／ＴＬＳ协议是应用范围非常广泛的密码协议之 一由于ＳＳＬ／ＴＬＳ本身的复杂性，版本更新的缓慢以 及实现维护过程的不重视，协议的设计与实现过程存 在许多漏洞。此外，因其保护数据安全的特殊性使得 ，其主要的目的是为网络中通信的双方建立一个安 协议存在很大的攻击价值，针对ＳＳＬ／ＴＬＳ出现的攻击 与１３剧增：降级攻击 、重协商攻击 、Ｌｕｃｋｙ Ｔｈｉｔｒｅｅｎ 攻击 ｊ、ＰＯＯＤＬＥ攻击 ｊ、ＢＥＡＳＴ攻击 、Ｈｅａｒｔｂｌｅｅｄ 攻击 ］、时问差分攻击 Ｊ、因代码实现问题产生的攻 全的通信信道。而这个信道需要为通信双方提供认 证、机密性和完整性。该协议也是实际应用中的最复 杂的密码协议之一，拥有高度的复杂性，版本众多，扩 收稿日期：２０１７—０２—２０。国家自然科学基金项目（６１４７２０８４）；上海市科委项目（１６ＤＺ１１００２００）。沈若愚，硕士生，主研领域 密码与信息安全。卢盛祺，博士生。赵运磊，教授。 第１１期 沈若愚等：ＴＬＳ１．３协议更新发展及其攻击与防御研究 ２６５ 击 。 等。这些攻击造成的危害与影响面的广泛为当下 的网络安全敲响一记警钟。而ＴＬＳ１．２版本的发布距 今已有８年，从近ｌＯ年针对协议的攻击数量的增长来 看，亟需重新制定ＴＬＳ协议的１．３版本。ＴＬＳ１．３协议 当客户端和服务器端双方第一次建立连接时可通 过握手协议协商协议版本，选择密码算法，认证通信双 方，协商算法所需参数，且能防篡改。握手协议完成 后，记录协议用握手协议协商好的算法和参数对消息 流进行分块加密。 １．２．１握手协议 的更新与发展过程值得信息安全学术界和产业界的广 泛关注。 １ ＳＳＬ／ＴＬＳ协议简介 ＳＳＬ起源于Ｎｅｔｓｃａｐｅ，ＳＳＬ３．０＿９ 于１９９６年发布， 如图２所示，握手协议有三个阶段： １）密钥交换：选择协议版本和密码算法，协商算 法所需参数，为明文传输。 ２）服务器参数：建立其他的握手协议参数，如是 否需要认证客户端，消息由握手层流密钥（ｈａｎｄｓｈａｋｅ ｔｒａｆｆｉｃ ｓｅｃｒｅｔ）加密传输。 对后续ＴＬＳ的发展有着基本的指导作用。其确定了协 议目标，整体的层次结构（主要由记录协议和握手协 议组成）以及消息流的顺序。目前的最高版本为 ＴＬＳ１．２ １ 。由于之前版本过于陈旧，存在许多的漏 洞，协议遭受的攻击越来越多，严重危及互联网安全。 互联网工程任务组开始筹划制定新的版本 ＴＬＳ１．３［１１］。 ３）认证：认证通信双方（客户端认证可选），并保 证握手消息的完整性，消息由握手层流密钥加密传输。 这三个阶段完成后，便可进行应用层数据的传输， 应用层数据由流密钥（ｔｒａｆｉｃ ｓｅｃｒｅｔ）加密后传输。ｆ 客户端 客户端Ｈｅｌｌｏ（协议版本＋隧机数＋会活、 ＩＤ＋密码套件＋压缩算法十扩展消息） ＋密钥共享 ｆ群＋密钥交换信息） １．１ ＳＳＬ３．０一ＴＬＳ１．３发展历程 ＳＳＬ／ＴＬＳ的更新发展过程如表１所示。协议的具 服务器端 体内容，详见参考文献［９—１２］。ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）文档是由互联网工程任务组发布的一系列 备忘录，是用以记录互联网规范、协议及过程等的标准 文件。 表１ ＳＳＬ／ＴＬＳ历史版本 ＴＬＳ协议版本 ＳＳＬ３．０ Ｅ ］ ＋预共事秘钥模式 （秘钥交换模式） ＋预共享密钥 （ＩＤｓ＋绑定值） ； 密钥交换１ 【｛ ｆ ｌ服务器端Ｈｅｌｌｏ（协【义版本＋随机 ｝ｆ数＋密码套件＋扩展消息） 鬲 ＋预共享密钥 ｌＩＤ） ＲＦＣ文档 ＲＦＣ６１Ｏｌ 时间 １９９６ Ｉ务器参数Ｉ ｛加密扩展Ｊ ｄ广展消 ，｛ｆ证书请求｝ 滞俅内容＋签名算 认Ｉｌ 法＋认征中心＋扩展消息） 证｛ 函丽 面 ＴＬＳ１．０ （ＳＳＬ３．１） ＲＦＣ２２４６ ＲＦＣ４３４６ １９９９ ２００６ （证书验证ｌ （签名算法＋签名） ｆ握手完成｝饿证数ｔ￣ＭＡＣ） ［应用数据 ＴＬＳ１．１ ＴＬＳ１．２１‘ ］ ＲＦＣ５２４６ ２００８ ｛证书Ｊ （请求内容十证书列表： ｛证书验证｝ （签名算法＋签名） ＴＬＳ１．３ ２０１４年４月开始制定，现未正式发布 ｆ握手完成Ｊ（验证数据ＭＡＣ） 【应用数据ｌ １．２ ＴＬＳ１．３协议结构 ＴＬＳ１．３由三部分组成，握手协议、警告协议和记 注：＋：上一消息的扩展消息； ：可选发送； 录协议。如图１灰色方框所示。其在ＴＣＰ／ＩＰ协议中 介于应用层协议和可靠的传输层协议之间，且于 应用层协议，因此可以置于很多不同的协议之下，如 Ｈｒ丌Ｐ、ＦｒＰ、ＳＭＴＰ、ＸＭＴＰ等。 ｛｝：用握手层流密钥加密；［］：用流密钥加密 图２ ＴＬＳ握手协议消息流 １．２．２记录协议 记录协议位于握手协议下层，发送方从高层接受 任意长度的非空数据，对其进行合并或分块处理，然后 利用带有辅助数据的认证加密ＡＥＡＤ（ａｕｔｈｅｎｔｉｃａｔｅｄ ｅｎｃｒｙｐｔｉｏｎ ｗｉｔｈ ａｓｓｏｃｉａｔｅｄ ｄａｔａ）进行加密传输。接收方 ＨＴＴＰ Ｉ ＦＴＰ Ｉ ＳＭＴＰ 握手协议ｆ警告协议 应用层 记录协议 传输层 网络层 ＴＣＰ ＩＰ 接收数据后对其进行解密和验证，重组后再传送给高 层用户。记录协议得到要发送的消息之后，进行如图 ３所示的两个步骤的处理。 链路层 ＡＲＰ 图１ ＴＬＳ协议所处位置 ２６６ 计算机应用与软件 ２０１７丘 上层数据 Ｉ Ｉ ＴＬＳＮ￣ 分 呛并 数据类型 协议版本ｌ消息长度ｌ消息片段 ＡＥＡＤＪＪ￣Ｉ密 ｆ数据类型ｌ协议版本ｆ消息长度 息片段＋数据类型＋填充字符ｌ 图３记录协议流程 分片：把上层数据分片或合并成易于处理的数据 分组，大小不超过２Ｈ字节。记录协议的数据类型有三 种：握手消息，应用数据，警告消息。警告消息的级别 有两种：一种是预警错误，用来指示连接的正常有序关 闭或者０－ＲＴＩ＇早期数据发送结束，对通信过程没有影 响；一种是致命错误，用来指示连接的非正常关闭，收 到这类警告消息后通信双方应立即中断会话，不再收 发消息。注意：对记录层消息进行分片处理时不能对 警告消息进行分块处理。此外，握手消息和警告消息 的消息长度不能为０，应用数据的消息长度可以为０， 用来防范针对流量分析的攻击。 载荷保护：将明文数据通过ＡＥＡＤ认证加密算法 加密为密文，密文数据的长度略大于明文数据长度。 明文数据结构由消息片段，数据类型和任意长度的填 充０值这三个部分组成，作为ＡＥＡＤ的一个输入值计 算得到加密内容。ＴＬＳ密文数据结构包括四个部分： 数据类型、协议版本、消息长度和加密内容。其中数据 类型字段一直都被设置为应用数据，真实的数据类型 可以从明文的数据类型获取，该字段是为了兼容之前 版本而存在。协议版本与明文消息的协议版本功能一 模一样，一直被设置为０ｘ０３０１（ＴＬＳ１．０），真实的协议 版本可以从客户端和服务器端的Ｈｅｌｌｏ消息获取。因 此，ＴＬＳ密文中的数据类型和协议版本这两个字段在 后续版本中可能会被除去。 ０值填充主要是为发送方隐藏真实数据长度而设 计。接收方解密密文后，从后往前读取数据，直到遇到 非０的值，即明文的数据类型这一字段。 ２ ＴＬＳＩ．３主要改变 ＴＬＳ１．３从２０１４年４月１７日起开始更新，至今更 新到ＴＬＳ１．３ Ｄｒａｆｔｌ８ ｌ１３］版本。本节将深入梳理并讨论 ＴＬＳ１．３相对于ＴＬＳ１．２的几个革新性的改变。 ２．１ 握手层消息结构的改变 从图２握手协议的消息流可以看出，相较ＴＬＳ１．２， 握手协议的结构发生了较大改变：移除“改变密码规 范”和“密钥交换”消息；为通信双方新增了几个Ｈｅｌｌｏ 扩展消息且新增“请求重新握手”消息；“握手完成”消 息对握手层的所有消息进行哈希，进一步保证了消息 的完整性。握手协议从之前的四个交互步骤简化为三 个步骤。 ２．２算法的移除与更新 计算机的软硬件各方面性能都得到了极大的提 升，计算速度以惊人的速度在增长，攻击方法也一直在 涌现。因此，之前认为安全的算法于近期及将来都不 能确保数据安全，亟需选择可靠性、安全性更高的算法 来替换易被攻击的算法。ＴＬＳ１．３移除的算法主要有： ＤＨ、ＲＣ４、记录层压缩算法、重协商、一些不安全的利 用率不高的椭圆曲线算法，以及哈希算法（如ＭＤ５、 ＳＨＡ．１、ＳＩ－ＩＡ．－２２４等）。新引入的算法有：ＡＥＡＤ算法， 以及从ＲＦＣ４４９２（ＥＣＣ Ｃｉｐｈｅｒ Ｓｕｉｔｅｓ ｆｏｒ ＴＬＳ）中引入 ＣＦＲＧ曲线和签名算法等。 ２．３密钥生成表 ＴＬＳ握手协议协商生成一个或多个密钥，如图４ 所示，以这些密钥作为输入通过哈希密钥推导提取函 数和哈希密钥推导扩展函数推导出多个记录层所需的 密钥。哈希密钥推导提取函数按照箭头方向从上接收 参数做加盐操作，从右边接收因特网密钥管理参数。 密钥扩展函数有三个输入值：密钥、标签和握手消息。 按照图４箭头方向所示从上端接收参数作为第一个密 钥参数。 』 哈希密钥推导提取函数 一ＰＳＫ Ｊｒ 荜ｊｌＩＩ辩铂 ｝ 挂；ｌ手密铂 ——————＇．密钥拓脯培ｒ］端握手流密锐＋“客，、端Ｈ ｌ０服务器ｌｌｅ￣ｔ￣’）＝客户端妊手流密销 卜＿—————— 密钥拓展（卅＆务器握手流密销＋“客户端Ｈｃｌｌ０・服务器Ｈｅ ’）＝服务措握手流密饲 ■ 哈希密钳推导提取函数●一ｔ） —————— 密销拓展（＋客户端流密钊＋‘客户端Ｈｅｌ１ｏ服务器握手完成”）＝客户端流密纠 Ｌ—一—— 密钥拓展（＋服务器流密销＋“客户端｝ｋＩｌ０服务器握手完成”）＝服务器流密铜 Ｌ—————十密钥拓展（＋会谮院复圭密诮＋“窬，－端№ｌｉｏ¨客， 端握手完成”）＝含ｉ舌恢复密钢 图４密钥生成表 由于不同的密码方案存在不同的安全性，需 要为不同的密码算法设置各自的密钥更新时间限度。 可结合握手层的“密钥更新”消息告知通信双方及时 更新密钥。 ２．４ ＰＳＫ ＰＳＫ预共享密钥交换模式主要是为了简化频繁通 信的双方握手协议的认证过程：如图５所示，共享有效 ２６８ 计算机应用与软件 ２０１７丘 主要是为了防止中问人攻击。握手消息从“客户端 Ｈｅｌｌｏ消息”开始到“预共享密钥的”ＩＤ字段为止，但不 包含绑定值本身。例如：客户端发送一个Ｈｅｌｌｏｌ消 息，绑定值的ＨＭＡＣ计算将只包含这个Ｈｅｌｌｏｌ消息； 如果客户端发送一个Ｈｅｌｌｏｌ消息，服务器回了一个 “请求重新握手”消息，客户端再发送一个Ｈｅｌｌｏ２消 息，绑定值的ＨＭＡＣ计算将包含：Ｈｅｌｌｏｌ＋请求重新 握手＋Ｈｅｌｌｏ２。 ２．５ ０．ＲＴＴ ＴＬＳ１．３支持“０一Ｒ１Ｔｒ（ＲｏｕｎｄＴｒｉｐＴｉｍｅ）”模式，客 户端在发送“客户端ＨｅＨｏ”等消息时可一并发送应用 层的数据，因此减少了握手延迟。０．Ｒ１Ｔｒ模式必须和 ＰＳＫ模式一起使用，０．Ｒｒ兀１数据由ＰＳＫ导出的早期流 密钥加密传输。０．ＲＴＴ的消息交互过程如图１０所示。 客户端ＨｅⅡ０（协议版本＋随机数＋会话、 ＩＤ＋密码套件＋压缩算法＋扩展消 ＋早期数据 ＋密钥共享 （群＋密钥交换信息） ＋预共享秘钥模式 （秘钥交换模式） 密钥交换 ＋预共享密钥 （ＩＤｓ＋绑定值） （应用数据） ＋早期数据结束（预警警告） 服务器端Ｈｅｌｌｏ（协议版本＋随机 ， 数栩§码套件＋扩展消息） ＋早期数据 密钥交换 ＋密钥共享 （群＋密钥交换信息） ＋预共享密钥 （ＩＤ） 服务器参数 ｆ加密扩展） 展消息） （握手完鼬（验证数据ＭＡｃ） 『应用数据】 ｌ｛握手完成】【验证数据ＭＡｃ）Ｊ ： ｌ……Ｌ…． Ｉ． ． ｌ ［应用数据Ｐ 注：＋：上一个消息的扩展消息； ：消息可选发送；（）：用客户端 早期流密钥加密；｛｝：用握手层流密钥加密；［］：用流密钥加密 图１０ Ｏ一Ⅳｎ握手协议消息流 这种模式没有完整版的ＴＬＳ握手协议安全：１）０－ Ｒ 数据不能保证前向安全，因为是用ＰＳＫ导出的早 期流密钥加密；２）不能保证不受重放攻击，除非服务 器采取协议外的防范措施。因此，各方针对０一ＲＴＴ的 讨论较为激烈。反对方认为：１）０一Ｒｒｒｒ存在上述两个 威胁，影响协议的安全性；２）１一ＲＴＴ模式已经能满足 要求，没必要引入隐患；３）协议的实现者不一定精通 密码学知识，盲目相信标准文档的安全性，且为了追求 效率使用０．ＲｒＩＴｒ，忽略了需要采取协议外的安全策略 这一需求。支持方则坚持：１）可以为了效率，对安全 性做出适当让步，且谷歌公司已经在使用这一方案且 效果良好；２）不宜直接反对并废除这一机制，应该给 通信双方选择的权利；３）可以把０．ＲＴＴ模式作为一个 扩展文档，与ＴＬＳ１．３标准文档区分，需要使用的时候 即可作为扩展包添加使用。 当客户端选择ＰＳＫ模式进行认证的时候，客户端 在发送“客户端Ｈｅｌｌｏ”消息时必须发送“早期数据”、 “预共享密钥模式”和“预共享密钥”消息。客户端可 以一直发送０－ＲＴＴ应用数据直到收到服务器的“握手 完成”消息，这时客户端需要发送“早期数据结束”预 警警告。服务器收到客户端的“早期数据”消息以后 有三种表现形式： １）忽略这个消息，不做任何应答，也即回归正常 的１一ＲＴＴ握手。 ２）发送“请求重新握手”消息，让客户端重新发送 Ｈｅｌｌｏ消息，该消息将不再包含“早期数据”消息。 ３）返回与之相应的“早期数据”扩展消息，接受０一 ＲＴＴ的早期数据。 ３ ＳＳＬ／ＴＬＳ攻击以及ＴＬＳ１．３防御措施 今年来，随着互联网的使用越加广泛和方便，越来 越多的数据和信息通过互联网进行传输。与此同时针 对ＳＳＬ／ＴＬＳ协议的攻击方法与日俱增，安全问题也逐 渐浮出水面。本节主要从协议的两层结构以及代码实 现这三个方面对近几年出现的攻击进行分类概述，并 讨论ＴＬＳ１．３针对这些攻击做出的改进方式。 ３．１针对握手层的攻击 １）降级攻击 降级攻击包括针对协议版本和针对密码中可用加 密方式的回滚攻击。由于ＴＬＳ１．２及之前的握手协议 中通信双方以明文传输的方式协商密码算法，中问人 攻击者可能通过冒充通信的某一方，诱使另一方修改 密码算法列表，将协议版本或加密算法降低到不安全 的却仍被双方都支持的版本，使得双方通信时使用安 全性较低的协议版本和较弱的加密算法。 ２）重协商攻击 其攻击原理主要是因为通信双方的身份不是和安 全信道绑定的，因此攻击者伪装成客户端与服务器进 行握手；建立了通信信道之后再将原客户端要发送的 握手信息接入这个安全信道中，完成再次握手，而通信 双方并不知情。 ３）防御措施 针对降级攻击，ＴＬＳ１．３移除了许多不安全的算 法，并且在服务器Ｈｅｌｌｏ消息的随机数字段中内嵌一 个降级攻击保护机制。另外，在握手结束消息中对整 个握手协议消息流内容进行哈希计算出消息认证码， 防止消息被中间人篡改。针对重协商攻击，ＴＬＳ１．３移 除了重协商这一功能。 第１１期 沈若愚等：ＴＬＳ１．３协议更新发展及其攻击与防御研究 ３）防御措施 ２６９ ３．２针对记录层的攻击 １ １ Ｌｕｃｋｙ Ｔｈｉｒｔｅｅｎ攻击 ＴＬＳ１．３采用ＡＥＡＤ算法，该算法会对待加密的明 文进行填充，隐藏真实数据长度，混淆了加解密过程与 时间的关联性。此外，ＴＬＳ１．３丰富了证书链表这一部 其攻击原理是ＨＭＡＣ验证计算时，去掉填充信息 之后消息的长度不同会导致计算时间上的区别。攻击 者对密文进行针对性的修改之后，根据ＨＭＡＣ验证的 处理时间长短可以获取关于密文的信息。 ２）ＰＯＯＤＬＥ攻击 其攻击原理主要是利用ＳＳＩ＿３．０协议中ＣＢＣ加密 算法零值填充无规律且填充字符的完整性在解密时不 能进行验证的缺陷。 ３）ＢＥＡＳＴ攻击 主要利用ＣＢＣ加密模式的链式结构，即除了第一 条记录之外，之后每条记录进行加密时的初始向量都 是前一条记录的最后一个加密块。攻击者通过某种方 式够获取密文一个块的信息，然后逐块破解一段密文。 ４）防御措施 ＴＬＳ１．３采用的ＡＥＡＤ算法可以避免Ｌｕｃｋｙ Ｔｈｉｒ－ ｔｅｅｎ攻击。ＴＬＳ１．３不允许将版本回退到ＳＳＬ３．０，且将 密文分组链接（ＣＢＣ）加密模式更换为计数器模式 （ＣＴＲ），避免了后两种攻击。 ３．３代码实现方面的攻击 在实现ＴＬＳ协议的时候，应用程序接口设计得较 差，且由于标准文档存在部分令人混淆的设置和选项， 开发者通常会误用、误解相关参数和选项的使用以及 返回值，造成程序实现错误。 １）Ｈｅａｒｔｂｌｅｅｄ攻击 主要是程序员在调用ｍｅｍｃｐｙ（）函数时没有对缓 冲区边界进行检查而造成的信息泄露。 ２）防御措施 ＴＬＳ１．３在附录Ｂ中增加了许多代码实现方面的 注意事项，如：伪随机数生成器的选取，握手协议某些 字段需要留意的特殊取值，如何预防计时攻击等。 ＴＬＳ１．３主要涉及协议标准的设计，代码的实现主要还 是依靠工程师，双方都需引起重视。比如，为ＴＬＳ库提 供模糊测试和敌手测试，设计一个简洁稳定的错误汇 报机制等。 ３．４其他攻击手段 １）时间差分攻击 针对对称算法和非对称算法都有计时攻击。其本 质是通过观察不同数据的加解密时间差实现密钥 破解。 ２）公钥证书验证缺失 ］ 另一个常见的攻击来源是公钥证书及其信任链验 证的缺失（尤其是基于移动终端的ＳＳＬ／ＴＴＬ实现）。 分的说明。 ４ ＴＬＳ１．３发展趋势 ｒＬＳ１．３目前一直处于更新状态，还有许多工作未 完成，专家学者正从多方面对协议的制定进行激烈的 讨论：小到算法的选取、参数长度的范围确定，大到新 机制的引入、协议安全性证明。 纵观当前讨论热点可总结出以下几个发展趋势： １）密码算法的选取、移除与更新；２）密码算法密钥的 长度以及相关参数范围的设置（最大值，最小值）；３） ０．Ｒ１Ｔｒ和ＰＳＫ模式的进一步优化；４）ＴＬＳ协议扩展文 件的更新；５）商讨、解决ＴＬＳ １．３ ｄｒａｆｔ文档中的ｏｐｅｎ ｉｓｓｕｅｓ；６）握手层协议安全性证明＿ｌ刮以及安全性分 析【】 这一方向的研究较难，但非常重要。 实际应用中，协议的安全与否主要由两个方面决 定：协议的设计与实现。目前针对协议设计的讨论众 多，但代码实现的安全性部分的考虑欠缺。本文作者 希望互联网工程任务组在制定新的标准的同时可以为 协议的代码实现人员提供一份说明文档，详尽说明协 议实现过程中可能会遇到的问题。比如，提供一份详 细的消息状态图和协议应用程序编程接口。标注标准 文档中安全性较弱的部分。除了对协议的结构的安全 性分析与证明，也希望相关学者以及互联网开发人员 重视协议代码安全实现这一方面的工作。 ５ 结 语 近年来，互联网安全性问题频发，ＳＳＬ／ＴＬＳ的安全 性研究引起广泛关注。本文从跟进ＴＬＳ协议新版本的 制定出发，对ＴＬＳ１．３几个革新性的改变：密钥编排表、 ＰＳＫ和０．Ｒ１Ｔ进行了分析与梳理，详细地描绘了协议 的结构以及握手层消息的交互过程。同时对近十年协 议受到的攻击按照协议的层次分类进行概述，提炼出 每种攻击的原理以及ＴＬＳ１．３针对这些攻击做出的应 对措施。最后对ＴＬＳ协议的更新发展趋势进行总结和 预测。伴随着ＴＬＳ１．３的制订，预计未来５年将迎来 ＴＬＳ研究的新机遇期。在未来的研究中将继续关注新 的密码协议的设计、安全性建模与分析、安全实现和形 式化验证、新型漏洞和攻击发展等。 （下转第３２９页） 第１１期 马晓凯等：基于安卓系统的代码隐藏类规避技术检测框架 ３２９ ［４］ Ｄａｌｖｉｋ Ｅｘｅｃｕａｔｂｌｅ Ｆｏｒｍａｔ［ＯＬ］．２０１６．ｈｔｔｐｓ：／／ｓｏｕｒｃｅ．ａｎ— ｄｒｏｉｄ．ｃｏｍ／ｄｅｖｉｃｅｓ／ｔｅｃｈ／ｄａｌｖｉｋ／ｄｅｘ—ｆｏｒｍａｔ．ｈｔｍ１． ［５］ Ｓｔｒａｚｚｅｒｅ Ｔ．Ｄｅｘ ｅｄｕｃａｔｉｏｎ：Ｐｒａｃｔｉｃｉｎｇ ｓａｆｅ ｄｅｘ［Ｍ］．Ｂｌａｃｋ Ｈａｔ，ＵＳＡ，２０１２． ［６］ Ｓｔｒａｚｚｅｒｅ Ｔ．Ｄｅｘ ｅｄｕｃａｔｉｏｎ ２０１：ａｎｔｉ—ｅｍｕｌａｔｉｏｎ［Ｍ］．ＨＩＴ． ＣＯＮ，２０１３． ［７］ Ｖｉｄａｓ Ｔ，Ｃｈｒｉｓｔｉｎ Ｎ．Ｅｖａｄｉｎｇ ａｎｄｒｏｉｄ ｒｕｎｔｉｍｅ ａｎａｌｙｓｉｓ ｖｉａ ｓａｎｄｂｏｘ ｄｅｔｅｃｔｉｏｎ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ９ｔｈ ＡＣＭ ｓｙｍｐｏ— ｓｉｕｍ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ，ｃｏｍｐｕｔｅｒ ａｎｄ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｅｃｕｒｉｔｙ． ＡＣＭ．２０１４：４４７—４５８． ［８］ Ｒｏｗｌａｎｄ Ｙｕ．Ａｎｄｒｏｉｄ Ｐａｃｋｅｒｓ：Ｆａｃｉｎｇ ｔｈｅ ｃｈａｌｌｅｎｇｅｓ， Ｂｕｉｌｄｉｎｇ ｓｏｌｕｔｉｏｎｓ［Ｃ］／／Ｐｒｏｃ．ｏｆ ｔｈｅ ２４ｔｈ Ｖｉｒｕｓ Ｂｕｌｌｅｔｉｎ Ｉｎ— ｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ，２０１４． ［９］Ｓｔｒａｚｚｅｒｅ Ｔ，Ｓａｗｙｅｒ Ｊ．Ａｎｄｒｏｉｄ Ｈａｃｋｅｒ Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌ ０ ＤＥＦ ＣＯＮ ２２【ｚ］．２０１４． ［１ ０］Ｚｈａｎｇ Ｙ，Ｌｕｏ Ｘ，Ｙｉｎ Ｈ．Ｄｅｘｈｕｎｔｅｒ：ｔｏｗａｒｄ ｅｘｔｒａｃｔｉｎｇ ｈｉｄ— ｄｅｎ ｃｏｄｅ ｆｒｏｍ ｐａｃｋｅｄ ａｎｄｒｏｉｄ ａｐｐｌｉｃａｔｉｏｎｓ［Ｍ］／／Ｅｕｒｏｐｅａｎ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｒｅｓｅａｒｃｈ ｉｎ Ｃｏｍｐｕｔｅｒ Ｓｅｃｕｒｉｔｙ．Ｓｐｒｉｎｇｅｒ Ｉｎ・ ｔｅｒｎａｔｉｏｎａｌ Ｐｕｂｌｉｓｈｉｎｇ，２０１５：２９３—３１１． ［１１］Ｙａｎｇ Ｗ Ｂ，Ｚｈａｎｇ Ｙ Ｙ，Ｌｉ Ｊ Ｒ，ｅｔ ａ１．ＡｐｐＳｐｅａｒ：Ｂｙｔｅｃｏｄｅ Ｄｅｃｒｙｐｔｉｎｇ ａｎｄ ＤＥＸ Ｒｅａｓｓｅｍｂｌｉｎｇ ｆｏｒ Ｐａｃｋｅｄ Ａｎｄｒｏｉｄ Ｍａｌ— ｗａｒｅｆＭ１／／Ｒｅｓｅａｒｃｈ ｉｎ Ａｔｔａｃｋｓ，Ｉｎｔｒｕｓｉｏｎｓ，ａｎｄ Ｄｅｆｅｎｓｅｓ． Ｓｐｒｉｎｇｅｒ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｕｂｌｉｓｈｉｎｇ，２０１５． ［１２］Ｒａｓｔｈｏｆｅｒ Ｓ，Ａｒｚｔ Ｓ，Ｍｉｌｔｅｎｂｅｒｇｅｒ Ｍ，ｅｔ ａ１．Ｈａｒｖｅｓｔｉｎｇ ｒｕｎｔ— ｉｍｅ ｖａｌｕｅｓ ｉｎ ａｎｄｒｏｉｄ ａｐｐｌｉｃａｔｉｏｎｓ ｔｈａｔ ｆｅａｔｕｒｅ ａｎｔｉ—ａｎａｌｙｓｉｓ ｔｅｃｈｎｉｑｕｅｓ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ａｎｎｕａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｎｅｔｗｏｒｋ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍ Ｓｅｃｕｒｉｔｙ（ＮＤＳＳ）．２０１６． ［１ ３］Ｒａｓｔｏｇｉ Ｖ，Ｃｈｅｎ Ｙ，Ｅｎｃｋ Ｗ．Ａｐｐ￣Ｐｌａｙｇｒｏｕｎｄ：ａｕｔｏｍａｔｉｃ ｓｅｃｕｒｉｔｙ ａｎａｌｙｓｉｓ ｏｆ ｓｍａｒｔｐｈｏｎｅ ａｐｐｌｉｃａｔｉｏｎｓ［Ｃ］／／Ｐｒｏｃｅｅｄ— ｉｎｇｓ ｏｆ ｔｈｅ ｔｈｉｒｄ ＡＣＭ ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄａｔａ ａｎｄ ａｐｐｌｉｃａｔｉｏｎ ｓｅ— ｃｕｒｉｔｙ ａｎｄ ｐｒｉｖａｃｙ．ＡＣＭ，２０１３：２０９—２２０． ［１４］Ｍｏｎｋｅｙ Ｒｕｎｎｅｒ［ＯＬ］．２０１６．ｈｔｔｐｓ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ． ｃｏｍ／ｓｔｕｄｉｏ／ｔｅｓｔ／ｍｏｎｋｅｙｒｕｎｎｅｒ／ｉｎｄｅｘ．ｈｔｍ１． ［１５］Ｓｍａｌｉ ａｎｄ ｂａｋｓｍａｌｉ：Ｄａｌｖｉｋ ｂｙｔｅｃｏｄｅ ｔｏｏｌｋｉｔ［ＯＬ］．２０１６． ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ＪｅｓｕｓＦｒｅｋｅ／ｓｍａｌｉ． ［１６］Ａｆｏｎｓｏ Ｖ，Ｂｉａｎｃｈｉ Ａ，Ｆｒａｔａｎｔｏｎｉｏ Ｙ，ｅｔ ａ１．Ｇｏｉｎｇ ｎａｔｉｖｅ： Ｕｓｉｎｇ ａ ｌａｒｇｅ—ｓｃａｌｅ ａｎａｌｙｓｉｓ ｏｆ ａｎｄｒｏｉｄ ａｐｐｓ ｔｏ ｃｒｅａｔｅ ａ ｐｒａｃ— ｔｉｃａｌ ｎａｔｉｖｅ—ｃｏｄｅ ｓａｎｄｂｏｘｉｎｇ ｐｏｌｉｃｙ［ＯＬ］／／Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ａｎｎｕａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｎｅｔｗｏｒｋ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍ Ｓｅｃｕｒｉｔｙ（ＮＤＳＳ），２０１６． （上接第２６９页） 参考文献 ［１］Ｗａｇｎｅｒ Ｄ，Ｓｃｈｎｅｉｅｒ Ｂ．Ａｎａｌｙｓｉｓ ｏｆ ｔｈｅ ｓｓｌ ３［Ｊ］．Ｐｒｏｃｅｅｄ— ｉｎｇｓ ｏｆ ｔｈｅ Ｓｅｃｏｎｄ Ｕｎｉｘ Ｗｏｒｋｓｈｏｐ ｏｎ Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ， １９９６，２８（２８）：２９—４０． ［２］Ｇｉｅｓｅｎ Ｆ，Ｋｏｈｌａｒ Ｆ，Ｓｔｅｂｉｌａ Ｄ．Ｏｎ ｔｈｅ ｓｅｃｕｒｉｔｙ ｏｆ ＴＬＳ ｒｅｎｅ— ｇｏｔｉａｔｉｏｎ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０１３ ＡＣＭ ＳＩＧＳＡＣ ｃｏｎ— ｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ＆ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｅｃｕｒｉｔｙ．ＡＣＭ． ２０１３：３８７—３９８． ［３］Ｆａｒｄａｎ Ｎ Ｊ Ａ，Ｐａｔｅｒｓｏｎ Ｋ Ｇ．Ｌｕｃｋｙ Ｔｈｉｒｔｅｅｎ：Ｂｒｅａｋｉｎｇ ｔｈｅ ＴＬＳ ａｎｄ ＤＴＬＳ Ｒｅｃｏｒｄ Ｐｒｏｔｏｃｏｌｓ［Ｃ］／／ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ．ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ，２０１３：５２６ —５４０． ［４］ＭＳｌｌｅｒ Ｂ，Ｄｕｏｎｇ Ｔ，Ｋｏｔｏｗｉｃｚ Ｋ．Ｔｈｉｓ ＰＯＯＤＬＥ ｂｉｔｅｓ：ｅｘ— ｐｌｏｉｔｉｎｇ ｔｈｅ ＳＳＬ ３．０ ｆａｌｌｂａｃｋ［ＯＬ］．２０１４．ｈｔｔｐｓ：／／ｗｗｗ． ｏｐｅｎｓｓ１．ｏｒ＃～ｂｏｄｏ／ｓｓｌ—ｐｏｏｄｌｅ．ｐｄｆ． ［５］Ｄｕｏｎｇ Ｔ，Ｒｉｚｚｏ Ｊ．Ｈｅｒｅ Ｃｏｍｅ Ｔｈｅ①Ｎｉｎｊａｓ［Ｊ］．Ｕｎｐｕｂ— ｌｉｓｈｅｄ Ｍａｎｕｓｃｒｉｐｔ，２０１ １． ［６］强小辉，陈波，陈国凯，等．ＯｐｅｎｓｓＬＨｅａｎＢｌｅｅｄ漏洞分析 及检测技术研究［Ｊ］．计算机工程与应用，２０１６，５２（９）： ８８—９５． ［７］Ｂｒｕｍｌｅｙ Ｄ，Ｄａｎ Ｂ．Ｒｅｍｏｔｅ ｔｉｍｉｎｇ ａｔｔａｃｋｓ ａｒｅ ｐｒａｃｔｉｃａｌ［Ｊ］． Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋｓ，２００５，４８（５）：７０１—７１６． ［８］Ｇｅｏｒｇｉｅｖ Ｍ，Ｉｙｅｎｇａｒ Ｓ，Ｊａｎａ Ｓ，ｅｔ ａ１．Ｔｈｅ ｍｏｓｔ ｄａｎｇｅｒｏｕｓ ｃｏｄｅ ｉｎ ｔｈｅ ｗｏｒｌｄ：ｖａｌｉｄａｔｉｎｇ ＳＳＬ ｃｅｒｔｉｉｆｃａｔｅｓ ｉｎ ｎｏｂ—ｂｒｏｗｓｅｒ ｓｏｆｔｗａｒｅ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０１２ ＡＣＭ ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ ａｎｄ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｅｃｕｒｉｔｙ．ＡＣＭ，２０１２：３８ —４９． ［９］Ｆｒｅｉｅｒ Ａ，Ｋａｒｌｔｏｎ Ｐ，Ｋｏｃｈｅｒ Ｐ．Ｔｈｅ ＳＳＬ ３．０ Ｐｒｏｔｏｃｏｌ［Ｚ］． Ｎｏｖｅｍｂｅｒ １９９６． ［１０］Ａｌｌｅｎ Ｃ，Ｄｉｅｒｋｓ Ｔ．Ｔｈｅ ＴＬＳ ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ １．０ ［Ｚ］．１９９９． ［１ １］Ｄｉｅｒｋｓ Ｔ，Ｒｅｓｃｏｒｌａ Ｅ．Ｔｈｅ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ） Ｐｒｏｔｏｃｏ１ Ｖｅｒｓｉｏｎ １．１『Ｒ］．ＲＦＣ ４３４６，ＤＯＩ １０．１７４８７／ ＲＦＣ４３４６，Ａｐｒｉｌ ２００６． ［１２］Ｄｉｅｒｋｓ Ｔ，Ｒｅｓｃｏｒｌａ Ｅ．Ｔｈｅ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ） Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．２［Ｒ］．ＲＦＣ ５２４６，ＤＯＩ １０．１７４８７／ ＲＦＣ５２４６，Ａｕｇｕｓｔ ２００８． ［１ ３］Ｒｅｓｃｏｒｌａ Ｅ．Ｔｈｅ Ｔｒａｎｓｐｏ￣Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．３［Ｒ］．ｄｒｆａｔ—ｉｅｔｆ－ｔｌｓ—ｔｌｓｌ３—１８，２０１６． ［１４］Ｓａｌｏｗｅｙ Ｊ．Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）Ｓｅｓｓｉｏｎ Ｒｅｓｕｍｐ— ｔｉｏｎ ｗｉｔｈｏｕｔ Ｓｅｒｖｅｒ—Ｓｉｄｅ Ｓｔａｔｅ［Ｚ］．Ｔｒａｎｓｐｏｒｔ，２００６． ［１５］Ｃｌａｒｋ Ｊ，Ｏｏｒｓｃｈｏｔ Ｐ Ｃ Ｖ．ＳｏＫ：ＳＳＬ ａｎｄ ＨＴＴＰＳ：Ｒｅｖｉｓｉｔｉｎｇ Ｐａｓｔ Ｃｈａｌｌｅｎｇｅｓ ａｎｄ Ｅｖａｌｕａｔｉｎｇ Ｃｅｒｔｉｆｉｃａｔｅ Ｔｒｕｓｔ Ｍｏｄｅｌ Ｅｎ－ ｈａｎｃｅｍｅｎｔｓ［Ｃ］／／Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ．ＩＥＥＥ，２０１３：５１１— ５２５． ／ ［１６］ Ｂｈａｒｇａｖａｎ Ｋ，Ｆｏｕｒｎｅｔ Ｃ，Ｋｏｈｌｗｅｉｓｓ Ｍ，ｅｔ ａ１．，／Ｐｒｏｖｉｎｇ ｔｈｅ ＴＬＳ Ｈａｎｄｓｈａｋｅ Ｓｅｃｕｒｅ（ａｓ ｉｔ ｉｓ）［Ｊ］．Ｌｅｃｔｕｒｅ Ｎｏｔｅｓ ｉｎ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ，２０１４，８６１７：２３５—２５５． ［１７］Ｄｏｗｌｉｎｇ Ｂ，Ｆｉｓｃｈｌｉｎ Ｍ，Ｎｔｈｅｒ Ｆ，ｅｔ ａ１．Ａ Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ａ‘ ｎａｌｙｓｉｓ ｏｆ ｔｈｅ ＴＬＳ １．３ Ｈａｎｄｓｈａｋｅ Ｐｒｏｔｏｃｏｌ Ｃａｎｄｉｄａｔｅｓ［Ｃ］／／ Ｔｈｅ．ＡＣＭ Ｓｉｇｓａｃ Ｃｏｎｆｅｒｅｎｃｅ．ＡＣＭ，２０１５：１ １９７—１２１０．
