没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
试读
15页
1. Linux磁盘加解密实现必读文档。 2. Linux磁盘加解密的内核实现为dm-crypt,用户层接口依据LUKS标准实现,因此在Linux上实现磁盘加解密需要了解LUKS标准接口。 3. LUKS1 是“Linux 统一密钥设置”的缩写。它最初的开发是为了解决用户因更改用户空间而获得加密设置以及忘记命令行参数而产生的不愉快。此更改的结果是无法访问的加密存储。发生这种情况的原因是,读取、处理和设置加密密钥的方式不规范,如果用户不走运,他会升级到用户空间工具的不兼容版本,需要大量知识才能与旧加密一起使用卷。 4. LUKS 的发明是为了标准化密钥设置 。
资源推荐
资源详情
资源评论
LUKS1 On-Disk Format Specication
Version 1.2.3
Clemens Fruhwirth <clemens@endorphin.org>
January 20, 2018
Document History
Version Date Author
Changes
1.0 22.01.2005 Clemens Fruhwirth <clemens@endorphin.org>
More clear distinction between raw data and string data by adding
a byte[] data type for LUKS magic, salt and checksum data.
1.0.1 15.01.2006 Clemens Fruhwirth <clemens@endorphin.org>
Corrected the hash-spec length in Figure 1 from 64 to 32 bytes
as implied by oset calculation and all other assumptions in this
document.
1.1 18.02.2006 Clemens Fruhwirth <clemens@endorphin.org>
Added precise AFsplit specication. Removed lrw-plain mode
spec as the LRW standardization process is not about to be n-
ished any time soon; will be reintroduced when a normative doc-
umentation is released by SISWG. Extended introduction text.
Thanks to Sarah Dean for providing valuable feedback with re-
spect to the AFsplit specication.
1.1.1 08.12.2008 Clemens Fruhwirth <clemens@endorphin.org>
Clarify IV reference point for decrypt/encrypt. Thanks to Michael
Gorven for this suggestion.
1.2 11.04.2011 Milan Broz <mbroz@redhat.com>
Fix hash block size/digest size AF comment. Clarify master key
digest iteration count. Add XTS mode reference. Some minor
typo xes. Add reference to NIST SP 800-132.
1.2.1 16.10.2011 Milan Broz <mbroz@redhat.com>
Mention detached header. Typo correction and some editing
for punctuation, grammar and clarity. Thanks to Karl O. Pinc
<kop@meme.com>.
1.2.2 4.5.2016 Milan Broz <mbroz@redhat.com>
Clarication of xed sector size and keyslots alignment.
1.2.3 20.1.2018 Milan Broz <gmazyland@gmail.com>
Fixed links to inline document sources.
1
1. OVERVIEW 2
Introduction
LUKS
1
is short for ”Linux Unied Key Setup”. It has initially been developed
to remedy the unpleasantness a user experienced that arise from deriving the
encryption setup from changing user space, and forgotten command line argu-
ments. The result of this changes are an unaccessible encryption storage. The
reason for this to happen was, a unstandardised way to read, process and set up
encryption keys, and if the user was unlucky, he upgraded to an incompatible
version of user space tools that needed a good deal of knowledge to use with
old encryption volumes.
LUKS has been invented to standardise key setup. But the project became
bigger as anticipated, because standards creation involves decision making,
which in turn demands for a justication of these decision. An overspring of this
eort can be found as TKS1 [Fru04], a design model for secure key processing
from entropy-weak sources
2
. LUKS is also treaded extensivly in Chapters 5 and
6 in “New Methods in Hard Disk Encryption”, which provides a theoretic base
for the security of PBKDF2 passwords and anti-forensic information splitting.
See [Fru05b].
LUKS is the proof-of-concept implementation for TKS1. In LUKS 1.0, the
implementation switched to TKS2, a varient of TKS1, introduced in [Fru05b].
Additionally to the security provided by the TKS1 model, LUKS gives the user
the ability to associate more than one password with an encrypted partition.
Any of these passwords can be changed or revoked in a secure manner.
This document species the structure, syntax and semantic of the partition
header and the key material. The LUKS design can be used with any cipher
or cipher mode, but for compatibility reasons, LUKS standarises cipher names
and cipher modes.
While the reference implementation is using dm-crypt, Linux’ kernel facility
for bulk data encryption, it is not tied to it in any particular way.
Next to the reference implementation which works on Linux, there is a Win-
dows implementation named LibreCrypt (based on original FreeOTFE project
by Sarah Dean).
1 Overview
A rough overall disk layout follows:
LUKS phdr
KM1 KM2
…
KM8
bulk data
A LUKS partition starts with the LUKS partition header (phdr) and is
followed by key material (labelled KM1, KM2 …KM8 in gure). After the key
material, the bulk data is located, which is encrypted by the master key. The
phdr contains information about the used cipher, cipher mode, the key length,
a uuid and a master key checksum.
Also, the phdr contains information about the key slots. Every key slot
is associated with a key material section after the phdr. When a key slot
is active, the key slot stores an encrypted copy of the master key in its key
1
This document describes version 1 of the LUKS on-disk format.
2
such as a user password
2. PREREQUISITES 3
material section. This encrypted copy is locked by a user password. Supplying
this user password unlocks the decryption for the key material, which stores
the master key. The master key in turn unlocks the bulk data. For a key slot,
all parameters how to decrypt its key material with a given user password are
stored in the phdr (f.e. salt, iteration depth).
A partition can have as many user passwords as there are key slots. To
access a partition, the user has to supply only one of these passwords. If a
password is changed, the old copy of the master key encrypted by the old
password must be destroyed. Peter Gutmann has shown in [Gut96], how data
destruction shall be done to maximise the chance, that no traces are left on
the disk. Usually the master key comprises only 16 or 32 bytes. This small
amount of data can easily be remapped as a whole to a reserved area. This
action is taken by modern hard disk rmware, when a sector is likely to become
unreadable due to mechanical wear. The original sectors become unaccessible
and any traces of key data can’t be purged if necessary.
To counter this problem, LUKS uses the anti-forensic information splitter
to articially inate the volume of the key, as with a bigger data set the prob-
ability that the whole data set is remapped drops exponentially. The inated
encrypted master key is stored in the key material section. These sections are
labelled as ”KMx” in the gure above.
2 Prerequisites
2.1 Block encryption system
Instead of using cipher implementations like AES or Twosh internally, LUKS
reuses the block encryption facility used for the bulk data. The following syntax
is used in the pseudocode:
enc−data = e n c r y p t ( ci ph er −name , c i p h e r −mode , key , o r i g i n a l ,
o r i g i n a l − l e n g t h )
o r i g i n a l = d e c r y p t ( c i p h e r −name , c i p h e r −mode , key , enc−data ,
o r i g i n a l − l e n g t h )
If the encryption primitive requires a certain block size, incomplete blocks
are padded with zero. The zeros are stripped upon decryptions.
3
2.2 Cryptographic hash
A cryptographic hash is necessary for the following two prerequisites. In
PBKDF2 a pseudo-random function is needed, and for AFsplitting a diusion
function is needed. The pseudo-random function needs to be parameterisable,
therefore the hash function is used in a HMAC setup [BCK97].
The following syntaxes may omit the hash-spec parameter, because the
following pseudo code does not need a great variation of this parameter. The
parameter can be obtained from the partition header and will not change, once
initialised.
3
These primitives are also used for key material en/decryption. The key material is
always aligned to sector boundaries. If the block size of the underlaying encryption primitive
is larger than one sector, the pseudocode of section 4.1 has to be changed respectively.
剩余14页未读,继续阅读
资源评论
车联网安全杂货铺
- 粉丝: 648
- 资源: 38
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功