https://pastel.archives-ouvertes.fr/pastel-00834324Guillaume BarbuGuillaume Barbu. On the security of Java Card platforms against hardware attacks. Other [cs.OH].Télécom ParisTech, 2012. English. NNT : 2012ENST0037. pastel-008343240HAL Id：pastel-008343240提交日期：2013年6月14日0HAL是一个多学科的开放获取存档，用于存储和传播科学研究文档，无论其是否已发表。这些文档可以来自法国或国外的教育和研究机构，或者来自公共或私人研究中心。0HAL（开放式多学科存档）是用于存储和传播研究级科学文献的开放式存档，这些文献可以是已发表或未发表的，来自法国或国外的教育和研究机构，公共或私人实验室。0关于Java Card平台对硬件攻击的安全性0引用此版本：2012-ENST-0037EDITE - ED 130TELECOM ParisTechGuillaume BARBU0ParisTech博士学位0博士论文0授予者：0专业：“通信与电子”0公开提交和答辩人：02012年9月3日0关于Java Card™平台对硬件攻击的安全性0论文导师：PhilippeHOOGVORST，论文共同导师：GuillaumeDUC，工业导师：Vincent GUERIN0评审委员会：Assia TRIA女士，SAS部门负责人，ENSMSE/CEA-LETI，评审人；Jean-LouisLANET先生，教授，XLIM，Limoges大学，评审人；Viktor FISCHER先生，教授，HubertCurien实验室，Saint-Étienne大学，评审人；Renaud PACALET先生，教授，SoC实验室，TélécomParisTech，评审人；Pascal URIEN先生，教授，INFRES部门，Télécom ParisTech，评审人；PhilippeHOOGVORST先生，研究员，COMELEC部门，Télécom ParisTech，论文导师；Vincent GUERIN先生，JavaCard和GlobalPlatform团队经理，Oberthur Technologies，指导教师；Éric VÉTILLARD先生，JavaCard首席产品经理，Oracle Inc.，嘉宾0TELECOM ParisTech是巴黎高科技学院的一部分iii0致谢0在此，我要衷心感谢在我完成这篇论文和撰写这篇手稿的过程中一直陪伴我的所有人：谢谢！0啊！不行！年轻人，这有点少！我们可以说...哦！天啊！总之，可以说很多事情...变换一下语气，比如说：0学术方面：感谢Philippe Hoogvorst和GuillaumeDuc对我的指导和建议。也要特别感谢TélécomParisTech的ComElec实验室的成员，特别是Jean-Luc Danger和SylvainGuilley，他们发起了这个论文并激发了我投入这个项目的热情。在这方面，还要感谢PhilippeGaborit。0Candidatorial* 1：感谢Assia Tria，Jean-Louis Lanet，Viktor Fischer，RenaudPacalet，Pascal Urien，Éric Vétillard和PierreParadinas（尽管由于某些不明原因和繁忙的日程安排，后者无法正式成为我的论文答辩委员会成员），他们同意参与对本论文所做的工作的评估。0企业方面：感谢Oberthur Technologies给予我将研究工作具有强烈工业特色的机会。0Collèg(u)ial*：感谢我的佩萨克同事们，尽管我在足球方面的信念与他们不同（幸运的是我并不孤单！）。特别感谢那些参与我的工作的人：Philippe Andouard，Stéphane Arzur，MatthieuBoisdé，Nicolas Bousquet，Olivier Chamley，Marc Dubuisson，Hugo Grenèche，NicolasMorin和Florent Oulières。感谢我的队友（现任和前任）：Nicolas Vasseur，SolineRenner和AlbertoBattistello，按时间顺序排列。也感谢那些迄今为止还没有参与进来的人（但我不会放弃！）：Stéphane Andrau，Angie Coppé，Patrick Davieaud，Yannick Manot，StéphanieSouchard，Jérémy Billaud，Gabriel Gomez，Benoît Linxe，Soazic Landais和SamuelDuclou。最后，特别感谢那些没有他们，这篇论文可能不会有同样的价值的人：VincentGuerin。01 带星号的形容词确实是新词0Christophe Giraud和Hugues Thiebeauld。0外科手术：感谢体育诊所和HIA RobertPicqué的骨科服务给我提供了一些时间来对我的工作进行一些反思，并在每次需要时帮助我恢复健康...运动对健康真的很危险！;-)0共和国：感谢法兰西共和国通过法国国家技术研究局资助这个论文，并让我能够进行（几乎）免费、世俗和（不总是）强制性的学习。0博士生：非常感谢Darreau的同事们，总是为我在他们的办公室找到一个位置，为（科学的）讨论和在露台上休息。0编辑：再次感谢我的合著者：Hugues Thiebeauld，Vincent Guerin，PhilippeHoogvorst，Guillaume Duc，Christophe Giraud和PhilippeAndouard。确实有时很难确定是否需要一个逗号，或者不需要...是否一个词真的比另一个好，或者不好...是否满足页面限制而不影响边距，或者不影响...0煽动性：感谢读者，因为他本质上证明了这份文件的写作的必要性。0友情：这个论文也标志着我作为学生的最后几年。因此，我还要感谢那些在这些年里白天和晚上陪伴我的人，"巴黎人"（这是世界其他地方称呼你们的方式...法国的其他地方），"利摩日人"（即使真正的利摩日人只有一只手指），"波尔多人"（最后是SAM篮球队！）。0家庭：我不能仅仅因为这个而感谢他们，但是非常感谢我的父母一直支持我，并让我能够继续我的学业到这个高级阶段。我还要感谢我的小妹妹...嗯，我的小妹妹...还有说我本可以感谢你审阅和修正这篇（不是）论文！:p 还要感谢整个家庭！0个人：最后，非常感谢我的小Carole为我带来的一切，并每天忍受（我的）研究的各种变数：文章和论文的审阅和截止日期，演示文稿的重复，参加会议的旅行。0-这大约是您会对我说的话，如果您有一些文化和才智的话[...]0v0摘要0本论文的主题是对JavaCard平台的硬件、软件和组合攻击进行研究，并保护这些平台免受此类攻击。0背景和现状0本论文的第I部分介绍了本论文工作的总体背景，并简要描述了智能卡安全和JavaCard平台安全的现状。0智能卡简介0第1章介绍了智能卡的概念。智能卡在许多日常应用中起着至关重要的作用，每个人都在日常生活中使用。这是因为智能卡已成为通过加密手段确保个人和/或机密数据的机密性和完整性的首选方式。0不同应用领域的发展，如银行卡支付、移动通信、交通卡验证等，导致这些卡的大规模部署。另一个推动这项技术快速增长的因素是自1987年以来全球标准化的重要努力，使得同一张卡可以在世界各国使用。0另一方面，尽管智能卡的某些物理特性遵循严格的标准，但其他特性却因卡片而异。特别是，构成芯片的不同电子组件随着技术进步而发展，并根据制造商和应用目标而变化。0嵌入式系统的硬件攻击0由于它们所包含的敏感信息，智能卡成为许多攻击的目标。特别是硬件攻击是一种严重的威胁，并在第2章中介绍。这类攻击包括两种类型的攻击：辅助信道分析攻击（SCA）和故障分析攻击（FA）。0辅助信道分析（SCA）和故障分析（FA）攻击。0SCA攻击旨在通过信息泄漏（例如组件执行操作所花费的时间，电力消耗或操作期间的电磁辐射）来获取组件处理的数据（通常是加密密钥）的信息。0FA攻击依赖于攻击者在操作期间对组件进行物理干扰。这种干扰可以通过不同的方式实现（例如电压峰值，电磁场峰值，光辐射峰值），并且可能会对应用程序的执行流程或组件处理的值产生不同的影响。0这两种类型的攻击主要针对嵌入式密码算法进行研究。0Java Card技术0第3章介绍了JavaCard技术，这是本文所描述的工作的核心。它于1996年推出，并迅速在智能卡行业中占据主导地位。0这一巨大的成功主要归功于JavaCard技术使得智能卡应用程序的开发和部署成本大大降低。事实上，它提供了一个抽象层（JavaCard虚拟机），使得同一个Java Card应用程序可以在任何实现JavaCard规范的智能卡上运行，而不受芯片的硬件特性和本地指令集的限制。0JavaCard应用程序是用Java语言的一个子集编写的，然后编译并可能转换为一个标准化的二进制文件，其中包含Java Card虚拟机可以理解的指令，称为字节码。0围绕这项技术还有一个生态系统，可以轻松地将JavaCard平台集成到智能卡的各个应用领域中。此外，JavaCard平台能够容纳多个应用程序（称为多应用平台），并允许在发行后加载应用程序（即在卡片交付给用户后加载应用程序）。0最后，Java Card规范定义了多种机制来确保平台本身以及其所包含的应用程序的安全性。0针对Java Card的攻击现状0作为智能卡领域的主导平台，JavaCard就像个人计算机领域的Windows系统一样，是攻击者的首选目标。第4章展示了科学界如何试图绕过JavaCard平台的某些安全机制，利用加载和执行潜在恶意应用程序的可能性。我们将看到，这些应用程序可以使攻击者通过软件攻击和SCA攻击获取有关平台或嵌入式应用程序的信息。0然而，我们随后将介绍，大多数公开发表的攻击仍然充分利用了部署应用程序的便利性，并使用所谓的格式错误应用程序（即不符合Java Card语言规则的应用程序）来绕过某些安全规则。0这些应用程序实际上很容易通过修改编译和转换步骤的二进制文件（即CAP文件）来生成。图1展示了一个格式错误应用程序的简单生成过程。事实上，只需修改二进制代码中的一个字节就足以使应用程序违反Java语言的规则。0图1：生成格式错误应用程序0/ / 与赋值语句相对应的指令序列：obj1 = obj2 / / obj1和obj2是Java对象的实例。aload_1 (0 x19 )astore_2 (0 x2D )0/ / 修改后的指令序列，用于固定对象实例的引用（地址）/ /obj2的加载是被禁止的（在Java语言中） iload_3 (0 x23 ) astore_2 (0 x2D )0随着静态代码分析工具的广泛使用，禁止加载这些格式错误的应用程序（尤其是字节码验证器）的攻击变得不太现实。0然而，正如我们在本文中所看到的，所谓的联合攻击（CombinedAttack）的引入（即恶意应用程序和一个或多个故障注入的结合）对这些工具提供的安全性构成了威胁，因此对Java Card平台的安全性产生了新的挑战。0安全分析，攻击路径的研究0本文第二部分描述了进行联合攻击分析的结果。0Bon-Typage属性0第5章介绍了我们对Bon-Typage属性进行安全分析的结果，该属性确保对象始终按照其类型（Java类）使用，并且特别确保对象不能像标量值一样使用。0这个属性是Java系统安全的基石，主要是因为它禁止对对象引用进行算术操作。因此，攻击者很有可能试图通过引发类型混淆来破坏这个属性。0本章描述了两种导致类型混淆的方法，并介绍了在JavaCard平台上利用类型混淆的不同攻击。这些攻击要求攻击者有机会在目标JavaCard上加载应用程序。如果不能保证在卡上加载应用程序的权利，那么平台的安全性必须考虑这种情况，因为这种权利是必要的。0checkcast指令的干扰。第一种方法是第一种公开发表的结合故障注入和恶意应用的攻击。该攻击是与Hugues Thiebeauld和Vincent Guerin一起开发的，并在2010年的CARDIS会议记录中发表[BTG10]。0这项工作实际上有两个创新点：0• 首先，此类联合攻击以前从未被利用过。0• 其次，此攻击针对Java Card最新版本（Java Card 3 ConnectedEdition），这是第一个要求嵌入式应用程序验证工具的版本，因此禁止任何格式错误应用程序的版本。0所述攻击是干扰JavaCard平台的特定指令的执行，以确保类型转换操作的有效性：由代码行中的类型转换操作符（()）生成的checkcast指令。0此攻击涉及到在Listing 2中定义的三个类A、B和C的内部表示，如图1所示。public class A {byte b00 , . . . , bFF;}public class B {short addr ;}public class C {A a ;}Class BClass Cshort addrA aaccess instanceas of type Baccess instanceas of type Cheader@ classowner context (fw)C cB bc.ab.addr0Listing 2: 涉及的类0图1：类B和C的实例的内部表示0因此，攻击的原理是利用对象的内部结构来伪造实例字段c.a的引用，如图2所示。0图2：将同一个对象作为B类或C类的实例访问0攻击的活动部分是在Listing3中描述的应用程序的执行以及对应于第10行的checkcast指令的干扰。0这种干扰在OberthurTechnologies安全实验室的激光攻击台上成功实施。图3和图4展示了Listing3的process方法执行的功耗测量结果。0Listing 3: 恶意applet0public class AttackExtApp extends Applet { B b ; C c ; booleanclassFound ; . . . / / 构造函数（初始化），install方法 public void process (APDU apdu ) { byte [ ] buffer = apdu . getBuffer ( ) ; . . . switch ( buffer [ISO7816 . OFFSET_INS ] ) { case INS_ILLEGAL_CAST : try { c = ( C ) b ; / /激光照射的目标操作 return ; / / 成功 } catch ( ClassCastException e ) { / *失败 * / } } } } }0分别是没有干扰和有干扰的情况下。0图3：applet的INS_ILLEGAL_CAST指令的执行0操作数堆栈的干扰。第二种方法是针对JavaCard虚拟机的一个关键组件，即操作数堆栈的攻击。事实上，JavaCard虚拟机定义的大多数指令都是将一定数量的操作数弹出堆栈，对这些操作数进行操作，然后将操作结果推入堆栈。这种攻击已经在Guillaume Duc和Philippe Hoogvorst的合作下，并在CARDIS 2011会议论文集中发表。0图4：applet的INS_ILLEGAL_CAST指令的干扰执行0图2：将同一个对象作为B类或C类的实例访问0发现对堆栈操作数的干扰还可以在恶意应用程序中引发类型混淆。在这种攻击的背景下，故障模型是在堆栈操作数堆栈更新期间干扰操作的结果，以使堆栈大小保持一致，但操作数未更新。0考虑一个连续压入两个不同类型的对象A和B的应用程序，忠实于定义的故障模型的干扰会导致类型A和B之间的混淆。此外，还引入了实例混淆的概念。0这个概念类似于类型混淆的概念，只是考虑了两个相同类型的实例或者两个实现同一个接口的不同类型的实例之间的混淆。清单4描述了用于实现此类实例混淆攻击的应用程序。0这种攻击在OberthurTechnologies安全实验室的激光攻击台上得到了实施。定义的故障模型得到了验证，攻击成功率接近10%。实验结果在附录A中给出。0清单4：恶意小程序0public interface I { / / 接口方法声明 } public class A implements I { / /接口方法的实现 } public class B implements I { / / 另一种接口方法的实现 } publicclass Application {0public I i; / / I类型的实例字段 public B b00, b01, . . . , bFF; / / 256个B类型的对象0public void confusion() {0b00 = new B(); / / .. . bFF = new (B);0A a = getA(); / / getA方法返回A类型的实例 / / 对堆栈的扰动有很大的机会 / /将返回的A类型对象的引用 / / 更改为B类型对象的引用之一。0类型混淆的利用。最后，介绍了不同的类型混淆利用。0其中之一是通过利用Java Card规范中定义的Class类的特性来修改嵌入式JavaCard应用程序的二进制代码。攻击者可以以任意方式修改自己的应用程序，从而将其转变为格式错误的应用程序，从而重新引入第4章中介绍的各种攻击。但攻击者也可以修改其他嵌入式应用程序的代码。给出的示例是删除实现电子签名验证操作的代码，从而在目标应用程序中获得某些特权。0第二种利用字符串在平台上的表示的攻击利用了String类。这种攻击表明，适当的类型混淆可以使攻击者的应用程序冒充平台上的另一个应用程序，通过修改表示URL（统一资源定位符，即地址）的字符串的内容而不修改其引用。请求访问合法应用程序的用户将被重定向到攻击者的应用程序，而不会被告知。这种攻击在E-SMART'10 [Bar10]会议上进行了介绍。/ /b = truei f(b){Util . setShort ( buffer ,( short ) 0 ,( short )0x1111 ) ;}else{Util . setShort ( buffer ,( short ) 0 ,( short )0x2222 ) ;}Util . setShort ( buffer ,( short )2 , proof ) ;0最后一种利用应用了实例混淆的概念。给出的实例混淆示例允许攻击者冒充授权用户的身份，通过混淆实现Authenticator接口的类的对象，该接口允许用户通过提供密码进行身份验证。在这里，实例混淆强制使用实现Authenticator接口的类的实例，其check方法（用于验证提交的密码的有效性）不执行任何检查，因此无论提交的密码是什么，都会验证身份。0执行流的完整性0很容易想象，扰乱应用程序的执行流程可能对其功能和安全性产生重大影响。因此，修改执行流程可能是攻击者的目标。第6章介绍了以不同的效果扰乱执行流程的方法以及这些扰乱可能产生的不同后果。0条件分支时操作数栈的干扰。正如第5章所述，第一次攻击再次涉及操作数栈的干扰。事实上，对于不同的条件分支指令（if_eq，if_ne），对其规范的分析揭示了其对先前定义的故障模型以及通常接受的故障模型的弱点。0这种弱点源于这些指令将操作数栈顶部的值与0进行比较，以决定是否执行分支。然而，正如前面所述，攻击者可能有能力干扰被推入栈中的值，从而无论与之关联的条件如何，都能强制执行分支。0通过在清单5中定义的代码上实践验证了攻击的有效性。0清单5：测试应用0故障注入的目标操作是变量b的入栈。0在执行ifeq指令之前，攻击的成功率相当惊人：78.25%。因此，很明显这些指令对于故障注入攻击非常敏感。类似的实验也在ifne指令的情况下进行，并获得了相同的结果。0多线程执行上下文的破坏。第二次攻击针对应用程序的执行流，利用了JavaCard的最新版本（Java Card 3.0 ConnectedEdition）的一个特性：多线程支持（即同时执行多个应用程序的支持）。该攻击的概念及其实现是与Hugues Thiebeauld合作完成的，并且该攻击的描述已经发表在2011年CARDIS会议的论文集中。0除了多线程，所设想的攻击场景还利用了平台的通信能力。特别是，它基于低级别接口与线程调度器的分离，轮流将卡片资源分配给不同的并发应用程序。0攻击场景可以通过图5来概括。0传入请求0线程20保存 加载0线程10线程20线程10图5：攻击场景0根据场景，攻击者可以通过在组件的通信线路上发送大量请求来强制在第一个线程的执行过程中在时间t发生线程切换。0通过在固定时间内递增计数器的应用程序同时向卡片发送大量通信请求来验证了这一点。正如预期的那样，图6显示了计数器达到的值。0随着通信请求数量的增加，其显著减少。0图6：通信对执行的指令数量的影响。0攻击的第二部分是破坏目标线程的执行上下文。这可以通过修改字节类型数组中的指针来实现，如图7所示。0混淆伪造长度和内存指针00字段10字段200内存指针0长度0长度0长度0伪造字节数组0图7：混淆两个类实例以伪造数组地址。0攻击者可以访问目标应用程序的执行上下文，随意修改局部变量的值，堆栈操作数中存储的值，甚至是java程序计数器（指向下一条要执行的指令），从而控制应用程序的行为。0为了展示这种攻击的威力，我们说明了它如何绕过被认为是强大的安全机制，如电子签名。0干扰与异常相关的机制。在本章的最后一部分，我们研究了针对与异常相关的机制的攻击。这项工作是与Philippe Hoogvorst和Guillaume Duc一起进行的，并发表在SECRYPT2012会议论文集中[BHD12b]。0Java中的异常原则允许将特定错误或更一般地将特定情况与特定处理程序关联起来。这些异常的语法在清单6中给出。0清单6：异常的语法0try { . . . / / 执行一系列可能会"抛出"不同异常的代码 . } catch ( ExceptionType1 et1 ) { . . . / /特定情况导致抛出特定异常。在这里"捕获"它。 } catch ( ExceptionType2 et2 ) { . . . / /特定情况导致抛出特定异常。在这里"捕获"它。 } f i n a l l y { . . . / /在抛出或未抛出异常的情况下执行的代码。 }0在应用程序的二进制格式中，不同的异常处理程序按照顺序列在每个定义的方法的表中。因此，当抛出异常时，虚拟机有责任通过在该表中查找来将执行流重定向到正确的处理程序。0我们的研究发现，在异常抛出和查找适当的处理程序的阶段中，不同的干扰可以破坏应用程序的执行流。0事实上，在异常抛出阶段，异常引用的干扰可能导致执行流重定向到错误的处理程序，从而在抛出的异常类型和处理程序所期望的异常类型之间创建类型混淆。0此外，另一种类型的错误可能只是阻止异常被抛出。0类似地，在查找适当的处理程序的阶段，影响查找算法的故障注入可能会将执行流重定向到错误的处理程序。0应用程序间的隔离0在多应用平台中，确保不同应用之间的严格隔离是至关重要的，无论是在它们的代码还是它们处理的数据方面。第7章介绍了针对Java Card平台提供的隔离机制的不同攻击。0代码隔离和类加载器。本章中描述的第一种攻击质疑了JavaCard规范中的代码隔离机制，通过共享对象（SIOs）的概念来实现。这种攻击在E-SMART'09会议上进行了介绍[Bar09]。0对象共享的原则是通过公开一个共享接口来声明对其他应用程序（即客户端）可访问的方法。服务器包含一个实现该共享接口的类。大多数情况下，除了在共享接口中定义的方法之外，服务器还定义了私有方法，这些方法不是共享的。0所描述的攻击旨在从客户端应用程序中访问服务器的私有方法。它首先基于两个实现相同共享接口的类之间的类型混淆。这种类型混淆可以通过第5章中介绍的两种方法之一引发。0通过这种混淆，攻击者可以获得服务器的私有方法的可见性。代码隔离被破坏，攻击者可以调用非共享的方法。然而，为了执行这个方法，攻击者还必须绕过数据隔离机制或应用程序防火墙。0通过应用程序重播绕过应用程序防火墙。如前所述，应用程序防火墙是JavaCard平台安全性的重要机制。这里介绍的第二种攻击是基于JavaCard规范的最新版本引入的新功能：垃圾回收机制。这种攻击是与PhilippeHoogvorst和Guillaume Duc共同开发的，并发表在ESSOS 2012会议论文集中[BHD12a]。0这种攻击基于对象引用的线性分配，即如果在时间t时分配的引用(r i) 1 ≤ i ≤ n满足1 ≤ r i ≤k，则下一个分配的引用将由r n +1定义为：0r n +1 = min { r i s.t. � r j < r i , r j is allocated } (1)0换句话说，下一个分配的引用将是可用的第一个引用。这个假设已经在不同的JavaCard规范实现上成功测试过。0基于这个假设，并利用垃圾回收机制的引入，攻击者能够预测将要使用的引用。然而，这种新能力并不是本文所描述的攻击的唯一原因。事实上，我们注意到Java Card 3.0 ConnectedEdition和其前身在应用程序删除机制方面存在重要差异。0与先前版本的规范要求在删除应用程序时删除该应用程序的所有对象不同，最新版本要求更少，只要求这些对象无法访问，即可能被垃圾回收机制删除。0因此，通过结合预测和伪造对象引用的能力，攻击者能够删除一个应用程序并阻止垃圾回收机制在下一次执行时删除这些对象。0假设应用程序防火墙通过为每个应用程序分配一个标识符来工作，我们可以认为攻击者有可能安装一个具有与已删除应用程序相同标识符的应用程序，其对象已被保留。攻击者可以合法地访问这些对象，从而绕过应用程序防火墙。0使用全局数组。全局数组是JavaCard平台中的特殊对象，不受应用程序间隔离机制的限制。在本章的最后部分，我们将介绍如何通过故障注入非法地使用这种类型的数组。这种攻击特别能够破坏许多应用程序中使用的安全通信协议。这个攻击是与Christophe Giraud和Vincent Guerin共同构思的，并发表在SEC2012会议论文集中[BGG12]。0故障注入在此攻击中用于绕过平台强制执行的限制，该限制禁止应用程序存储对全局数组的引用。如果成功，此故障注入将允许攻击者将全局数组的引用存储为卡片的通信缓冲区：APDU缓冲区（应用协议数据单元）。0此攻击的后续部分展示了利用管理卡片的环境（GlobalPlatform）或将其集成到移动电话（USIMToolkit）中的某些机制的方法，以从这种情况中获利。0此外，对于支持多线程的平台，利用这种攻击还可以绕过由安全通道（SecureChannel）提供的安全性，该通道用于确保卡片上的应用程序与终端之间的通信的机密性和完整性。0Java卡应用程序0INIT_UPDATE(HRAND)0RESP(CRAND,CCRYPT)0EXT_AUTHENTICATE(HCRYPT)0RESP(OK/NOK)0E(CMD)||MAC0CMD0嵌入式攻击者0安全通道安全通道0Java卡终端0CMD0终端应用程序0标准攻击者0RESP RESP0图8：嵌入式攻击者窃听和破坏通信。0图8说明了此攻击的利用。0Java卡的安全性贡献0本论文的第三部分证明了结合物理干扰和恶意软件的攻击对Java卡平台的安全性构成威胁。第三部分描述了本论文对Java卡平台安全性的不同贡献。0攻击性、防御性和防御性虚拟机...0首先，第8章概述了攻击性、防御性和防御性虚拟机的概念。0在攻击性和防御性虚拟机中，系统的安全性依赖于加载到卡中的代码的静态分析工具，称为字节码验证器（bytecodeverifier）。该工具通过与语言规则相比较来确保加载的代码的有效性。特别是，完美的字节码验证器禁止加载任何格式错误的应用程序，从而隐式地阻止基于此类应用程序的任何攻击。
我的内容管理
展开
