安全分析：TPM2.0哈希消息认证码授权在数字版权管理中的形式化研究
3 浏览量
更新于2024-08-29
收藏 1.2MB PDF 举报
"这篇研究论文深入分析了在数字版权管理（DRM）场景下，可信平台模块（Trusted Platform Module, TPM）2.0版本基于哈希的消息认证码（Hash-Based Message Authentication Code, HMAC）授权机制的安全性。作者对TPM 2.0的HMAC授权方案进行了形式化分析，并将其与TPM 1.2的‘对象独立授权协议’和‘对象特定授权协议’进行了详尽对比。此外，他们利用类型化Dolev-Yao模型计算来描述TPM 2.0 HMAC授权的过程，并评估其安全属性。"
本文关注的是可信计算领域中的核心组件——TPM，特别是其最新的2.0版本。TPM是整个可信计算平台的信任根，它的安全性直接影响到系统的整体安全。TPM 2.0引入了HMAC授权机制，这是一种增强安全性的身份验证方法，它使用哈希函数和密钥来验证消息的完整性和来源。
HMAC授权方案作为安全协议被详细阐述，其目的是确保在DRM环境下，只有经过正确授权的实体才能访问和处理受保护的内容。DRM是数字内容保护的重要工具，防止非法复制和分发。通过比较TPM 2.0与前一代TPM 1.2的授权协议，研究者揭示了新版本在安全性和效率上的改进，包括更强大的加密算法、更灵活的授权策略和更严密的认证过程。
为了深入理解TPM 2.0 HMAC的授权流程，研究人员运用了类型化Dolev-Yao模型，这是一种常用于形式化安全分析的理论模型。这个模型允许分析者在假设攻击者可以读取和复制消息，但不能伪造密钥或签名的情况下，描述和评估协议的安全性。通过这种方式，研究者能够识别潜在的安全漏洞，并评估TPM 2.0 HMAC授权在抵御中间人攻击、重放攻击和其他常见安全威胁时的能力。
这篇论文为理解TPM 2.0在DRM环境下的HMAC授权机制提供了深入的见解，同时对提高数字内容的安全保护和确保用户隐私具有重要意义。对于IT安全领域的专业人士来说，这是一项重要的研究，有助于提升对可信计算平台安全设计的理解和实践。
F. Y u
et al.
Analysis of TPM 2.0 HMAC authorization under DRM scenario
used the extended finite state machine model model for
generating the test cases and analyze the testing results.
The paper [31] developed a secure compiler for distributed
information flows, relying on TPM 1.2 to minimize trusted
computing base. This paper presented a security model for
these mechanisms in an imperative language. Similarly,
TPM 2.0 also provides its functional support to the exter-
nal entity by its commands or APIs. It is necessary to use
formal methods to analyze the security properties of TPM
2.0 to judge whether it has the security flaws.
We mainly make the following contributions in this paper:
(i) describe the TPM 2.0 HMAC authorization scheme as
a security protocol between the TPM and the caller; (ii)
make a detail comparison of the TPM 2.0 authorization to
the TPM 1.2 OIAP and OSAP; (iii) Use the typed pi cal-
culus to describe the TPM 2.0 HMAC authorization and
its security properties under the DRM scenario; and (iv)
use ProVerify to reason that the key handle manipulation
flaw for TPM 1.2 does not exist any more in TPM 2.0,
because the access entity unique name has been linked to
the HMAC value, but the vulnerability of key blob substi-
tution still exists in TPM 2.0.
The remainder of this paper is organized as follows:
Section 3 gives an introduction of TPM 2.0 HMAC autho-
rization and makes a detail comparison with TPM 1.2;
Section 4 constructs the formal model of the TPM 2.0
HMAC authorization under DRM scenario and reason
whether the security properties hold by attack analysis;
and Section 5 concludes this paper and introduces the
future work.
3. TRUSTED PLATFORM MODULE
2.0 HASH-BASED MESSAGE
AUTHENTICATION CODE
AUTHORIZATION AND
COMPARISON WITH TRUSTED
PLATFORM MODULE 1.2
Many TPM 2.0 commands used by the caller require
authorizations. TPM 2.0 specification defines three autho-
rization types: password, HMAC, and policy. A plaintext
password authorization is appropriate for cases in which
the path between the caller and the TPM is trusted, or
when the authorization value is shared by users. HMAC
and policy both are session-based authorizations, which
begins by using TPM2_StartAuthSession(). Dur-
ing the HMAC authorization, the authValue of the entity
is used. During the policy authorization, the authPolicy of
the entity is used. A policy defines the conditions for use
of an entity. In TPM 2.0, the authPolicy is one (statisti-
cally unique) digest. TPM 2.0 specification only requires
that the two commands, TPM2_NV_ChangeAuth() and
TPM2_Duplicate(), must use a policy authorization.
Most TPM 2.0 commands can use HMAC authorizations.
This paper focuses on giving an analysis of TPM 2.0
HMAC authorization.
3.1. Trusted Platform Module 2.0
hash-based message authentication
code authorization
The TPM 2.0 HMAC authorization is illustrated by
Figure 1 with one example command and its associated
authorization session, which is described as a security
protocol between the caller and the TPM like TPM 1.2,
although there is no clear declaration that the HMAC
authorization is a protocol in the TPM 2.0 specifications
for some unknown reasons. The example command in
Figure 1 only has one entity handle handleA. Depending
on the specific command of TPM 2.0, zero to three han-
dles are used to identify the entities in TPM. The command
handle may have an associated authorization session, but
no currently defined TPM 2.0 command needs more than
two authorizations. This example command also has one
sensitiveData parameter in session-based encryption.
When starting the TPM 2.0 HMAC authorization
session by calling TPM2_StartAuthSession(),
the parameters, handleBind and handleKeyLoaded,
can be set NULL or valid values. The key associated
with handleKeyLoaded is used to encrypt the salt
value. If handleKeyLoaded=NULL, there is no salt
value. The salt value maybe symmetrically (including
XOR obfuscation and Cipher Feed Back mode (CFB)
encryption) or asymmetrically encrypted during trans-
mission, which depends on the key type associated with
the handleKeyLoaded. The function SaltEnc() is
defined as Equation (1), and SaltDec() is defined as
Equation (2), the nonceCaller used in CFBSymEnc()
and CFBSymDec() is acted as the Initialization Vector
(IV). The parameter of handleBind declares the spe-
cific access entity in the session. Based on the values
of handleBind and handleKeyLoaded, the TPM 2.0
authorization session can be classified into four types:
unbound and unsalted session (handleBind=NULL and
handleKeyLoaded=NULL), unbound and salted session
(handleBind=NULL and handleKeyLoaded¤NULL),
bound and unsalted session (handleBind¤NULL
and handleKeyLoaded
=NULL), bound and salted
session (handleBind¤NULL and handleKey-
Loaded¤NULL). The sensitiveData parameter in the
example command is in encrypted form during transmis-
sion, which needs one sessionKey. The sessionKey
creation of TPM 2.0 is explained as Equation (3). Unbound
and unsalted session does not support this session-based
encryption. The session-based parameter encryption of
TPM 2.0 can be XOR obfuscation or Cipher FeedBack
(CFB) model symmetrical encryption. The function
SessionEnc() and SessionDec() are defined as
Equation (4) and (5). TPM 2.0 supports that the ses-
sion bind handle handleBind is not the same as the
access entity handle handleA, which leads two small
different situations in XOR obfuscation-based session
encryption, cmdAuthHMAC (defined as Equation (6))
and rspAuthHMAC (defined as Equation (7)) genera-
tion. The authorization of the caller is achieved by the
Security Comm. Networks
(2015) © 2015 John Wiley & Sons, Ltd.
DOI: 10.1002/sec
剩余13页未读，继续阅读
2015-02-02 上传
2018-05-27 上传
2021-02-21 上传
2021-02-21 上传
2021-04-22 上传
2021-02-21 上传
2018-10-31 上传
2021-03-21 上传
2014-06-26 上传
weixin_38608189
- 粉丝: 4
- 资源: 922
我的内容管理
展开
最新资源
- 探索数据转换实验平台在设备装置中的应用
- 使用git-log-to-tikz.py将Git日志转换为TIKZ图形
- 小栗子源码2.9.3版本发布
- 使用Tinder-Hack-Client实现Tinder API交互
- Android Studio新模板：个性化Material Design导航抽屉
- React API分页模块：数据获取与页面管理
- C语言实现顺序表的动态分配方法
- 光催化分解水产氢固溶体催化剂制备技术揭秘
- VS2013环境下tinyxml库的32位与64位编译指南
- 网易云歌词情感分析系统实现与架构
- React应用展示GitHub用户详细信息及项目分析
- LayUI2.1.6帮助文档API功能详解
- 全栈开发实现的chatgpt应用可打包小程序/H5/App
- C++实现顺序表的动态内存分配技术
- Java制作水果格斗游戏：策略与随机性的结合
- 基于若依框架的后台管理系统开发实例解析
