没有合适的资源?快使用搜索试试~ 我知道了~
首页trusted computing platforms:design and applications
资源详情
资源评论
资源推荐
Chapter 2
MOTIVATING SCENARIOS
In this chapter, we try to set the stage for our exploration of trusted com-
puting platforms. In Section 2.1, we consider the adversary, what abilities and
access he or she has, and what defensive properties a trusted computing platform
might provide. In Section 2.2, we examine some basic usage scenarios in which
these properties of a TCP can help secure distributed computations. Section 2.3
presents some example real-world applications that instantiate these scenarios.
Section 2.4 describes some basic ways a TCP can be positioned within a dis-
tributed application, and whose interests it can protect; Section 2.5 provides
some real-world examples. Finally, although this book is not about ideology,
the idealogical debate about the potential of industrial trusted computing efforts
is part of the picture; Section 2.6 surveys these issues.
2.1
Properties
In its classic conception, a trusted computing platform such as a secure
coprocessor is an armored box that does two things:
It protects some designated data storage area against an adversary with
certain types of direct physical access.
It endows code executing on the platform with the ability to prove that it is
running within an appropriate untampered environment.
What types of attacks the platform defends against, and exactly how code does
this attestation, are issues for the platform architect.
In an informal mental model of a distributed computing application, we map
computation and data to platforms distributed throughout physical space. Users
(including potential adversaries) are also distributed throughout this space. Co-
location of a user and a platform gives that user certain types of access to
10
TRUSTED COMPUTING PLATFORMS
that platform: through “ordinary” usage methods as well as malicious attack
methods (although the distinction between the two can sometimes reduce to how
well the designer anticipated things). A user can also reach a platform over a
network connection. However, in our mental model, direct co-location differs
qualitatively. To illicitly read a stored secret over the network, a user must find
some overlooked design or implementation flaw in the API. In contrast, when
the user is in front of the machine, he or she could just remove the hard disk.
Not every user can reach every location. The physical organization of space
can prevent certain types of access. For example, an enterprise might keep
critical servers behind a locked door. Sysadmins would be the only users with
“ordinary” access to this location, although cleaning staff might also have “or-
dinary” access unanticipated by the designers. Other users who wanted access
to this location would have to take some type of action—such as picking locks
or bribing the sysadmins—to circumvent the physical barriers.
The potential co-location of a user and a platform thus increases the potential
actions a user can take with that platform, and thus increases the potential
malicious actions a
malicious user can take. The use of a trusted platform
reduces the potential of these actions. It is tempting to compare a trusted
platform to a virtual locked room: we move part of the computation away from
the user and into a virtual safe place. However, we must be careful to make
some distinctions. Some trusted computing platforms might be more secure
than a machine in a locked room, since many locks are easily picked. (As
Bennet Yee has observed, learning lockpicking was standard practice in the
CMU Computer Science Ph.D. program.) On the other hand, some trusted
computing platforms may be less secure than high-security areas at national
labs. A more fundamental problem with the locked room metaphor is that, in
the physical world, locked rooms exist before the computation starts, and are
maintained by parties that exist before computation starts. For example, a bank
will set up an e-commerce server in a locked room before users connect to it,
and it is the bank that sets it up and takes care of it. The trusted computing
platform’s “locked room” can be more subtle (as we shall discuss).
2.2
Basic Usage
This discussion leaves us with the working definition: a TCP moves part
of the computation space co-located with the user into a virtual locked room,
not necessarily under any party’s control. In more concrete terms, this tool has
many potential uses, depending on what we put in this separate environment.
At an initial glance, we can look on these as a simple 2x2 taxonomy: secrecy
and/or authenticity, for data and/or code.
Since we initially introduced this locked room as a data storage area, the first
thing we might think of doing is putting data there. This gives secrecy of data.
If there is data we do not want the adversary to see, we can shelter it in the
Motivating Scenarios
11
TCP. Of course, for this protection to be meaningful, we also need to look at
how the data got there, and who uses it: the implicit assumption here is that the
code the TCP runs when it interacts with this secure storage is also trustworthy;
adversarial attempts to alter it will also result in destruction of the data.
In Chapter 1, we discussed the difference between the terms “trustworthy”
and “trustable”. Just because the code in the TCP might be trustworthy, why
should a relying party trust it? Given the above implicit assumption—tampering
code destroys the protected data—we can address this problem by letting the
code prove itself via use of a key sheltered in the protected area, thus giving us
authenticity of code.
In perhaps the most straightforward approach, the TCP would itself generate
an RSA key pair, save the private key in the protected memory, and release
the public key to a party who could sign a believable certificate attesting to the
fact that the sole entity who knows the corresponding private key is that TCP,
in an untampered state. This approach is straightforward, in that it reduces
the assumptions that the relying party needs to accept. If the TCP fails to be
trustworthy or the cryptosystem breaks, then hope is lost. Otherwise, the relying
party needs only needs to accept that the CA made a correct assertion.
Another public key approach involves having an external party generate the
key pair and inject the private key, and perhaps escrow it as well. Symmetric
key approaches can also work, although the logic can be more complex. For
example, if the TCP uses a symmetric key as the basis for an HMAC to prove
itself, the relying party must also know the symmetric key, which then requires
reasoning about the set of parties who know the key, since this set is no longer
a singleton.
Once we have set up the basis for untampered computation within the TCP to
authenticate itself to an outside party—because, under our model, attack would
have destroyed the keys—we can use this ability to let the computation attest
to other things, such as data stored within the
TCP. This gives us authenticity
of data. We can transform a TCP’s ability to hide data from the adversary into
an ability to retain and transmit data whose values may be public—but whose
authenticity is critical.
Above, we discussed secrecy of data. However, in some sense, code is data.
If the hardware architecture permits, the TCP can execute code stored in the
protected storage area, thus giving us secrecy of code. Carrying this out in
practice can be fairly tricky; often, designers end up storing encrypted code in
a non-protected area, and using keys in the protected area to decrypt and check
integrity. (Chapter 6 will discuss this further.) An even simpler approach in this
vein is to consider the main program public, but (in the spirit of Kerckhoff’s
law) isolate a few key parameters and shelter them in the protected storage.
However, looking at the potential taxonomy simply in terms of a 2x2 ma-
trix overlooks the fact that a TCP does not just have to be passive receptacle
剩余10页未读,继续阅读
lcjj2012
- 粉丝: 0
- 资源: 2
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- 2022年中国足球球迷营销价值报告.pdf
- 房地产培训 -营销总每天在干嘛.pptx
- 黄色简约实用介绍_汇报PPT模板.pptx
- 嵌入式系统原理及应用:第三章 ARM编程简介_3.pdf
- 多媒体应用系统.pptx
- 黄灰配色简约设计精美大气商务汇报PPT模板.pptx
- 用matlab绘制差分方程Z变换-反变换-zplane-residuez-tf2zp-zp2tf-tf2sos-sos2tf-幅相频谱等等.docx
- 网络营销策略-网络营销团队的建立.docx
- 电子商务示范企业申请报告.doc
- 淡雅灰低面风背景完整框架创业商业计划书PPT模板.pptx
- 计算模型与算法技术:10-Iterative Improvement.ppt
- 计算模型与算法技术:9-Greedy Technique.ppt
- 计算模型与算法技术:6-Transform-and-Conquer.ppt
- 云服务安全风险分析研究.pdf
- 软件工程笔记(完整版).doc
- 电子商务网项目实例规划书.doc
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论1