云计算机熵源研究与网格系统安全建模
云计算机熵源相关研究
-
熵池处理机制
- 中断间隔时间与当前熵池内容作为扭曲通用反馈移位寄存器的输入,其输出反馈回熵池。若请求读取熵池,熵池会作为安全哈希算法(SHA)的输入,以增强熵池秘密状态的安全性。不过,虽然当前SHA被认为在这方面表现良好,但存在算法被分析从而遭受攻击的可能性。而且频繁调用SHA会带来严重的开销。
-
分布式与共享熵分布
- 不同服务类型的熵源分布 :在云系统中,不同服务级别提供不同类型的熵源。基础设施即服务(IaaS)系统中,熵源分布在各个实例中,每个实例生成自己的随机数;软件即服务(SaaS)和平台即服务(PaaS)可能所有服务共享一个公共的随机数池。
-
两种方式的优缺点
- 分布式熵生成 :优点是可控制随机数的生成方式,且能与可能的对手分离;缺点是可能会遭受对调度实例的特权操作系统的攻击。
- 共享熵系统 :恶意用户可能会比熵池填充速度更快地耗尽熵,导致其他用户性能下降甚至出现拒绝服务情况。若共享熵系统无法快速生成随机数,可能会限制对熵池的访问,甚至对访问进行市场化操作。在使用Xen虚拟化管理程序的云计算机中,高熵源稀缺。
-
Xen调度
-
Xen系统有多种调度器,用于决定下一个调度的操作系统。主要的三种调度器是借用虚拟时间(BVT)调度器、最早截止时间优先调度器(sEDF)和信用调度器。还有一个轮询调度器,用于简化攻击的演示。
- BVT调度器 :允许对延迟敏感的应用程序插队调度,但之后需要偿还CPU时间。
- sEDF调度器 :每次调度进程时,会在进程优先级队列中查找最早截止时间的进程。这两种调度器在未来Xen版本中可能会被弃用。
- 信用调度器 :是Xen维护者最推荐的调度器,任务基于货币系统进行调度,虚拟CPU(VCPU)在队列中调度并“支付”实际CPU时间,每个VCPU从会计系统获得配额。
-
Xen系统有多种调度器,用于决定下一个调度的操作系统。主要的三种调度器是借用虚拟时间(BVT)调度器、最早截止时间优先调度器(sEDF)和信用调度器。还有一个轮询调度器,用于简化攻击的演示。
-
对云熵源的攻击
- 随机数池耗尽攻击 :针对PaaS云可能具有的共享熵分布架构。
-
熵池中毒攻击
:针对IaaS云可能具有的分布式熵分布架构,是本文的重点。攻击者通过生成已知延迟的中断,将其作为输入通过Linux随机数生成器(RNG),从而了解其他用户熵池的内容。攻击事件包括:
- e0:清空熵池(耗尽至空后停止)。
- e1:开始发送TCP数据包。
- e2:停止发送TCP数据包。
- e3:读取整个熵池。
- e4:在时间片结束前传输或存储。
-
云熵管理系统
- 该系统旨在解决云实例熵生成的弱点,运行在云主机上,为客户提供更精确的熵池熵估计,并在云主机熵生产不足时提供救援熵。系统采用最少干预原则,让现有内核伪随机数生成器(PRNG)正常运行,同时提供更现实的熵估计。
- 操作流程:每个云主机运行一个服务器,为其上的实例提供服务。运行熵管理器的云实例启动时会连接到服务器,服务器提供云实例数量,作为客户熵估计的除数,该除数会广播给客户端。Linux PRNG使用更新后的估计值来控制生成的内部阈值。客户还可以向服务器请求熵包,测试时可通过HTTP GET请求从random.org获取2KB的数字采样大气噪声作为熵源,但存在安全问题,可通过加密或添加本地熵来解决。服务器程序设计允许灵活选择熵源。
-
实验研究与结果
- 构建实验云 :最初在亚马逊EC2云进行工作,但实验需要灵活性,因此搭建了私有Xen云平台,测试云主机采用Dell PowerEdge 2950服务器,配置为2x四核至强E5335处理器(2GHz)、8GB(667MHz)内存和500GB存储。
-
熵池中毒攻击实验
- 熵贡献变量 :Linux RNG中的熵贡献包括jiffie、num和cycle变量。jiffie是定时器中断计数器(Linux中每4ms一次),num表示中断类型,cycle是x86 CPU中以时钟频率运行的自由运行计数器寄存器。
- jiffie和num变量的不变性 :实验表明,前300秒后,domain 0和客户实例的jiffie数量不变,该问题可能被管理程序过滤,不影响客户。num变量在domain 0中变化显著,但在所有客户实例中完全静态。
-
cycle变量
:cycle变量在所有实例(包括客户和domain 0)中表现出更有趣且富含熵的行为。客户实例之间的cycle变量紧密耦合,而domain 0实例与客户实例基本独立。以下是相关的相关性和协方差表格:
| Instance (with Dom 0) | Correlation | Covariance |
| — | — | — |
| DomU1 | 0.177657311 | 0.2019764114 |
| DomU2 | 0.3175715104 | 0.2947513962 |
| DomU3 | 0.4681160782 | 0.5268961915 |
| DomU4 | 0.3753263986 | 0.3768116959 |
| Instance Pair | Correlation | Covariance |
|---|---|---|
| 2 Instances - DomU1 - 2 | 0.7698154055 | 0.7775670479 |
| 4 Instances - DomU1 - 2 | 0.6424939995 | 1.6548446143 |
| 4 Instances - DomU1 - 3 | 0.7283067151 | 0.7936474751 |
| 4 Instances - DomU1 - 4 | 0.893786794 | 2.2162510283 |
| 4 Instances - DomU2 - 3 | 0.8870338305 | 1.0030611841 |
| 4 Instances - DomU2 - 4 | 0.9862760451 | 0.9635573195 |
| 4 Instances - DomU3 - 4 | 0.8700133244 | 1.0424442764 |
-
结果分析
- 实验发现,假设通过在客户实例上生成中断来为domain 0熵池做贡献的能力大多是错误的,这使得熵池中毒攻击不太可能发生。但客户实例之间的相关性在大量样本运行中非常高,这违反了Linux RNG设计者关于贡献是唯一随机且只有RNG可知的假设。cycle变量的相关性可能是由于多核处理器中自由运行计数器寄存器在核心之间同步导致的。此外,样本中另外三分之二的变量的一般不变性会对熵池贡献的熵估计产生负面影响,num变量不变是因为其来源是生成事件的中断类型,而客户实例的I/O都来自网络,所以没有变化;jiffie变量不变可能是Xen尝试为客户处理jiffie时钟导致的,这会影响熵生成率。因此,提出的云熵管理系统可以提供解耦的救援熵,解决样本相关性问题。
网格系统安全建模
-
引言
- 如今,网格系统作为分布式计算系统,用于解决科学和商业领域的工作密集型和资源密集型任务。由于网格主机处理的信息价值较高,网格系统注重信息安全,特别是计算和信息资源的保护。这一问题是由分布式网格系统的特性导致的,如异构性、作业处理基础设施的共同所有权、高状态动态性和去中心化。用户作业在多个主机系统上远程处理,需要有效的方法来保护用户数据免受主机环境的影响。信息安全政策通过授权规定(通常是“主体 - 对象 - 权限”约束形式)来解决这个问题,但由于网格系统的特殊性,缺乏统一的数学工具来为作业处理中的每个实体定义这些要求,还需要考虑预定义的关系。
-
背景
-
网格系统资源分类
- 计算资源 :用于解决需要大量CPU时间或内存的劳动密集型任务。
- 存储资源 :作为用户信息存储在远程主机上。
- 软件资源 :用于处理用户自身软件环境中不可用的应用程序的数据。
- 网络资源 :用户不能直接使用,用于其他类型资源之间的通信。
- 虚拟组织(VO) :网格系统基于作业处理基础设施的共同所有权原则,通过VO机制实现。VO是一个动态的用户社区,他们共享网格系统资源以解决共同任务并遵循商定的规则。每个用户可以同时属于多个VO,且VO的内容变化非常大。这种特殊性质使得确保计算资源和用户数据的安全保护变得复杂,例如难以使用经典安全模型,也难以验证信息安全政策。
-
常见的计算机攻击类型
- 拒绝服务攻击 :通过针对网格系统基本服务的网络攻击,破坏整个系统的功能。
-
网格系统资源分类
云计算机熵源研究与网格系统安全建模
云计算机熵源研究后续讨论与结论
-
讨论
- 总体而言,Xen云平台并没有明显的实际安全漏洞,但客户实例的恢复率可能被高估,导致整个测试中的估计值虚高。虽然这使得理论上的密码分析攻击在假设情况下可能发生,但与其他存在高估问题的主机并无太大不同。这也是云熵管理系统采用除法机制的原因,低估熵比高估要好得多。
- 如果要克隆客户实例,应该在克隆前清空其熵池。克隆实例启动时,再次清空熵池,并重新生成密钥。在测试中虽然进行了克隆后清空熵池的步骤,但没有重新生成SSH密钥,导致所有实例的RSA指纹相同。处理克隆实例的共享状态,特别是打破需要唯一性的事物的共同状态,对于保护云实例是一项有意义的工作。不能低估用户的粗心,自动化这些任务的工具将非常有用。
- 云熵在负载均衡机制和克隆机制方面也存在潜在弱点。当实例在公共网络上进行负载均衡或克隆时,也应该清空熵池并重新生成密钥。
-
结论
- 研究揭示了Xen云平台主机中域U实例之间存在熵耦合的证据。如果攻击者控制足够多的实例,就有可能预测变量。
- 实验结果表明,虚拟化会影响熵样本的收集。特别是num变量在所有实验中都没有变化,而jiffie变量在所有实验中仅出现一次变化,显然大部分变化被虚拟化层过滤。
- cycle变量的高相关性令人担忧,这表明在Xen客户机上的熵收集需要在内核中进行不同的管理。云熵管理系统通过提供解耦的救援熵,避免了样本相关性问题。该系统的实现开销较低,由两个用Python编写的守护进程组成,为确保云客户机的熵估计和熵池不被利用提供了合理的方法。
网格系统安全建模的深入探讨
-
基于Petri网的访问控制模型
- 为了解决网格系统中计算和信息资源保护的问题,提出了基于Petri网的访问控制模型。该模型可以增强网格系统的安全性,确保“作业”提交符合安全策略约束,并验证网格系统中的安全实现。
- Petri网是一种用于描述和分析并发系统的数学工具,通过定义库所(Place)、变迁(Transition)和有向弧(Arc)来表示系统的状态和状态之间的转换。在网格系统的安全建模中,库所可以表示系统的不同状态,如用户权限、资源状态等;变迁可以表示系统中的事件,如用户请求资源、资源分配等;有向弧则表示状态和事件之间的关系。
-
具体操作步骤如下:
- 定义系统元素 :确定网格系统中的主体(如用户、进程)、对象(如计算资源、存储资源)和权限(如读取、写入、执行),将这些元素映射到Petri网的库所和变迁。
- 建立状态转换规则 :根据信息安全政策,定义主体对对象的访问规则,将这些规则转化为Petri网的变迁触发条件。例如,如果用户具有读取某一存储资源的权限,则相应的变迁可以被触发。
- 验证安全策略 :使用Petri网的分析方法,如可达性分析、活性分析等,验证所建立的安全模型是否满足信息安全政策的要求。例如,检查是否存在非法的状态转换,是否会出现死锁等情况。
-
模型优势
- 增强安全性 :通过严格遵循安全策略约束进行作业提交和验证,可以有效防止未经授权的访问和攻击,保护计算和信息资源的安全。
- 灵活性 :Petri网模型可以根据不同的网格系统和安全需求进行灵活调整,适应各种复杂的场景。
- 可验证性 :可以使用成熟的Petri网分析方法对模型进行验证,确保安全策略的正确实施。
以下是一个简单的Petri网模型示例(使用mermaid语法):
graph LR
classDef place fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef transition fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
P1([用户权限]):::place -->|请求资源| T1(资源分配):::transition
T1 --> P2([资源使用中]):::place
P2 -->|释放资源| T2(资源回收):::transition
T2 --> P3([资源空闲]):::place
这个示例展示了一个简单的用户请求资源、使用资源和释放资源的过程,通过Petri网可以清晰地表示系统的状态转换和事件触发。
综上所述,云计算机熵源研究和网格系统安全建模都是保障信息系统安全和可靠性的重要方面。云熵管理系统可以解决云实例熵生成中的问题,而基于Petri网的网格系统安全模型可以有效保护网格系统中的计算和信息资源。在实际应用中,需要根据具体情况选择合适的方法和技术,不断优化和完善系统的安全性。
超级会员免费看
71

被折叠的 条评论
为什么被折叠?



