保密安全与密码技术-9病毒课件.pptVIP

移动代码安全 移动代码安全技术 恶意代码 恶意主机 移动代码安全技术 移动代码又称移动代理、可下载代码、可执行内容、远程代码等等，它是指在本地执行的远程代码。传统系统中，执行的代码都是驻留在执行代码的主机上，而对于移动代码，执行的代码则是来自远程主机。 移动代码与传统的基于客户机—服务器技术的分布式系统作了比较： 移动代码安全技术 客户机—服务器模型：客户机和服务器位于不同的主机上，由客户机向服务器发送请求；处理请求所需的资源和代码都位于服务器端。 即时响应代码：客户机拥有完成某项操作的资源，但没有如何完成这项操作的代码，客户机通过向远程服务器发送请求，由服务器将代码发送给客户机。这种类型的移动代码包括：Java应用程序、ActiveX控件等。 远程计算：客户机拥有描述某项服务的代码，而执行代码所需的资源位于远程服务器上。客户机把代码发送到服务器上，由服务器执行代码并把结果回送到客户机。 移动代理：客户机进程在执行期间为了完成某项服务需要访问一些资源，而这些资源位于远程服务器上，于是客户机把客户机进程移植到服务器端并由服务器完成服务。客户机进程会一直停留在服务器上直到下一个客户机进程移植过来。 移动代码安全技术 移动代码会导致安全问题的本质在于在运行代码时需要访问系统资源，而代码却是来自于另一台，甚至是不可信的主机。即代码提供者和代码运行者之间可能是互不信任的。移动代码易受到以下几种类型的攻击： 泄漏用户或主机的机密信息； 拒绝服务：使合法用户无法获得资源； 破坏或修改数据； 恶作剧攻击：如在用户屏幕上显示图片或在用户主机上播放音乐等。 移动代码安全技术 移动代码安全需要考虑以下几个方面： 访问控制：规定谁可以使用代码； 用户认证：识别合法用户； 数据完整性：保证代码在传输过程中未被修改过； 不可抵赖：发送者和接收方不能否认使用过代码； 数据机密性：保护敏感数据； 审计：跟踪移动代码的使用。 在前面提到，移动代码安全可以从两个方面考虑：一是恶意代码对本地系统的破坏；二是远程恶意主机对代理的非法使用。接下来，我们将从恶意代码和恶意主机两个方面来讨论移动代码的安全技术。 恶意代码 对于Java应用程序类的移动代码，一般的操作是用户下载可执行格式的二进制Applet然后运行。这就很容易带来安全问题： 用户必须允许不可信的代码在本机运行，而这些代码可能会随机写内存，从而导致系统崩溃；代码甚至可以读、修改以至删除用户个人文件。 在运行Applet之前进行认证可以解决这个问题。通过认证，用户就可以确定它所运行的代码来自于特定的可信源。但是这种方法带来了两个问题： 严重限制了用户可以运行的Applet，而不可信服务器也可提供有用的、好的代码；更重要的是来自可信源的代码可能存在bug，从而对用户系统带来恶劣的影响。 对该问题的理想解决方法就是阻止不安全的行为。接下来讨论三种解决恶意代码问题的技术：安全解释器、故障隔离和代码验证。 恶意代码 安全解释器 直接运行二进制代码是很危险的，解决这个问题的常用方法是不使用编译好的可执行代码，而采用解释移动代码的方法。在这种情况下，解释器能很好地控制Applet并能检查每一条指令和每一个状态以决定是否执行Applet。这样，系统的安全性就在于实现解释器的安全策略的正确性上。安全解释器包括Safe-Tcl、Safe-Tcl扩展、Java等等。 故障隔离 采用安全的解释器系统能很好地解决恶意代码的问题。但是，相对编译的机器码而言，解释器存在严重的性能缺陷：执行Java Applet比执行一般的二进制代码要慢得多。为此可以转而采用一种称为“沙盒”(sandbox)的方法来获得安全。 恶意代码 故障隔离 在沙盒模式中，下载的不可信代码的操作将严格局限于沙盒中。 沙盒是由运行代码的主机特别为移动代码分配的地址空间。 这时，移动代码可以在沙盒中运行，但不会超出沙盒的界限。因此这种沙盒模式为移动代码提供了一个受限的运行环境，在此环境中可以运行从开放网络中获得的不被完全信任的代码(如Applet等)。 采用沙盒模式的主要缺点是可下载的代码不再是与平台无关的，而与操作平台无关原本是Java系统的主要设计目标之一。 恶意代码 代码验证 第三种技术是一种称为证明携带码PCC(Proof-Carrying Code)的技术。 Java Applet作者的任务不仅是把Applet编译成机器代码，还要产生一个安全证明(Safety Proof)，用来证明这个代码符合安全策略中指定的安全规则(Safety Rules)。 当用户下载代码后，它只要验证代码中的证明，看是否合法并满足安全规则就行。如果是则加载代码并运行它。 这种方法是否有效的关键在于哪些程序特性可以表示和证实。PCC已成功应用于最小和最大CPU周期限制、内存