blob: 2eea76518c01515c75a5c7a718a91c54afe25885 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
{{{
#!htmlcomment
This page is maintained automatically by a script. Don't modify this page by hand,
your changes will just be overwritten the next time the script runs. Talk to your
Friendly Neighborhood Repository Maintainer if you need to change something here.
}}}
{{{
#!html
<h1>keywrap</h1>
<h2>Introduction</h2>
<p>This core implememts AES KEY WRAP as defined in <a href="https://tools.ietf.org/html/rfc3394">RFC
3394</a> and the keywrap with padding
according to <a href="https://tools.ietf.org/html/rfc5649">RFC 5694</a></p>
<p>The core supports wrap/unwrap of objects up to 64 kByte in size.
The core supports 128 and 256 bit wrapping keys.</p>
<h2>Status</h2>
<p>First complete version developed. The core does work.</p>
<p>The core has been simulated with two different simulators and
linted. The core has been used on the Cryptech Alpha and verified to
work.</p>
<h2>API</h2>
<p>Objects to be processed are written in word order (MSB words). The
caller writes the calculated magic value to the A regsisters in word
order. The caller also needs to write the number of blocks (excluding
magic block) into the RLEN register. Finally the caller needs to write
the wrapping key.</p>
<p>Due to address space limitations in the Cryptech cores (with 8-bit
address space) the object storage is divided into banks [0 .. 127]. Each
bank supports 128 32-bit words or 4096 bits. For objects lager than 4096
bits, it is the callers responsibilty to switch banks when reading and
writing to the storage.</p>
<h2>Implementation details</h2>
<h3>Key Wrap</h3>
<p>The core implements the wrap block processing part of the AES Key Wrap
as specified in chapter 2.1.1 of RFC 3394:</p>
<p>For j = 0 to 5
For i=1 to n
B = AES(K, A | R[i])
A = MSB(64, B) ^ t where t = (n*j)+i
R[i] = LSB(64, B)</p>
<p>The core does not perform the calculation of the magic value, which is
the initial value of A. The core also does not perform padding om the
message to an even 8 byte block.</p>
<p>This means that SW needs to generate the 64-bit initial value of A and
perform padding as meeded.</p>
<p>(Similarly, the core implements the unwrap processng as specifie in
chapter 2.2.2 of RFC 3394.)</p>
<h3>Auto Zeroise</h3>
<p>The core implements an auto zeroise functionality for secret key. This
means that any loaded wrapping key will automatically be wiped from all
registers storing key information after a specified timeout. Timeout
countdown is halted when the core is performing any wrap/unwrap operation,
and the timeout is reset to its defined start value after an operation
has been completed.</p>
<p>SW can set the timout value (in cycles), SW can also inspect the key
status and timeout status. Reading status also triggers a reset of the
timeout counter. This allows SW to keep a loaded key alive by simply
checking status. Finally SW can actively trigger a key zeroisation
operation.</p>
<h2>Implementation results</h2>
<p>The core has been implemented for Xilinx Artix7-t200 using ISE with the
following results:</p>
<p>Regs: 2906 (1%)
Slices: 1991 (5%)
RamB36E: 32 (8%)
Clock: 100+ MH</p>
}}}
[[RepositoryIndex(format=table,glob=user/js/keywrap)]]
|| Clone `https://git.cryptech.is/user/js/keywrap.git` ||
|
