From a73e147ceb6f14750d8aa3e64a0aeffc60f3513c Mon Sep 17 00:00:00 2001 From: Tomas Susanka Date: Fri, 25 Jan 2019 15:07:36 +0100 Subject: [PATCH] readme: remove future tense; and key derivation image; other small typos --- README.md | 77 ++++---- docs/key-derivation.odg | Bin 0 -> 13948 bytes docs/key-derivation.svg | 411 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 454 insertions(+), 34 deletions(-) create mode 100644 docs/key-derivation.odg create mode 100644 docs/key-derivation.svg diff --git a/README.md b/README.md index c0733722bd..537e9157d7 100644 --- a/README.md +++ b/README.md @@ -10,12 +10,6 @@ The PIN is no longer stored in the flash storage. A new entry is added to the fl ## Storage format -The current format of the entries in the flash storage is: - -| Data | KEY | APP | LEN | DATA | -|----------------|-----|-----|-----|------| -| Length (bytes) | 1 | 1 | 2 | LEN | - Entries fall into three categories: | Category | Condition | Read | Write | @@ -24,33 +18,40 @@ Entries fall into three categories: | Protected | 1 ≤ APP ≤ 127 | Only when unlocked | Only when unlocked | | Public | 128 ≤ APP ≤ 255 | Always | Only when unlocked | -Private values are used to store storage-specific information and cannot be directly accessed through the storage interface. Currently the above conditions are enforced only in software, but not cryptographically. We propose that protected entries shall have the following new format:z +The format of public entries has remained unchanged, that is: + +| Data | KEY | APP | LEN | DATA | +|----------------|-----|-----|-----|------| +| Length (bytes) | 1 | 1 | 2 | LEN | + +Private values are used to store storage-specific information and cannot be directly accessed through the storage interface. Protected entries have the following new format: | Data | KEY | APP | LEN | IV | ENCRDATA | TAG | |----------------|-----|-----|-----|----|----------|-----| | Length (bytes) | 1 | 1 | 2 | 12 | LEN - 28 | 16 | -The LEN value thus indicates the total length of IV, ENCRDATA and TAG. The format of public entries shall remain unchanged. +The LEN value thus indicates the total length of IV, ENCRDATA and TAG. -The random salt (32 bits), EDEK (256 bits), ESAK (128 bits) and PVC (64 bits) will be stored in a single entry under APP=0, KEY=2: +The random salt (32 bits), EDEK (256 bits), ESAK (128 bits) and PVC (64 bits) is stored in a single entry under APP=0, KEY=2: | Data | KEY | APP | LEN | SALT | EDEK | ESAK | PVC | |----------------|-----|-----|-------|------|------|------|-----| | Length (bytes) | 1 | 1 | 2 | 4 | 32 | 16 | 8 | | Value | 02 | 00 | 3C 00 | | | | | -The storage authentication tag (128 bits) will be stored in a single entry under APP=0, KEY=5: +The storage authentication tag (128 bits) is stored in a single entry under APP=0, KEY=5: | Data | KEY | APP | LEN | TAG | |----------------|-----|-----|-------|-----| | Length (bytes) | 1 | 1 | 2 | 16 | | Value | 05 | 00 | 20 00 | | -Furthermore, if any entry is overwritten, the old entry will be erased, i.e., overwritten with 0. We could then also use APP=0, KEY=0 as marker that the entry is erased (currently this is the marker for the PIN entry that we wouldn't need anymore). +Furthermore, if any entry is overwritten, the old entry is erased, i.e., overwritten with 0. We are also using APP=0, KEY=0 as marker that the entry is erased (this was formerly used for the PIN entry, which is not needed anymore). ## PIN verification and decryption of protected entries in flash storage 1. From the flash storage read the entry containing the random salt, EDEK and PVC. + 2. Gather constant data from various system resources such as the ProcessorID (aka Unique device ID) and any hardware serial numbers that are available. The concatenation of this data with the random salt will be referred to as *salt*. 3. Prompt the user to enter the PIN. Prefix the entered PIN with a "1" digit in base 10 and convert the integer to 4 bytes in little endian byte order. Then compute: @@ -72,6 +73,8 @@ Furthermore, if any entry is overwritten, the old entry will be erased, i.e., ov where the APP and KEY of the entry is used as two bytes of associated data. Compare the TAG read from the flash storage with the computed tag value. If there is a mismatch, then fail. +![summary](docs/key-derivation.svg) + ## Initializing the EDEK 1. When the storage is initialized, generate the 32 bit random salt and 256 bit DEK using a cryptographically secure random number generator. @@ -104,31 +107,33 @@ Whenever the value of an entry needs to be updated, a fresh IV is generated usin The storage authentication key (SAK) will be used to generate a storage authentication tag (SAT) for the list of all (APP, KEY) values of protected entries (1 ≤ APP ≤ 127) that have been set in the storage. The SAT will be checked during every get operation. When a new protected entry is added to the storage or when a protected entry is deleted from the storage, the value of the SAT will be updated. The value of the SAT is defined as the first 16 bytes of -`HMAC-SHA-256(SAK, ⨁i HMAC-SHA-256(SAK, KEYi || APPi))` +`HMAC-SHA-256(SAK, ⨁i HMAC-SHA-256(SAK, KEY_i || APP_i))` -where `⨁` denotes the n-ary bitwise XOR operation and KEYi || APPi is a two-byte encoding of the value of the i-th (APP, KEY) such that 1 ≤ APP ≤ 127. +where `⨁` denotes the n-ary bitwise XOR operation and KEY_i || APP_i is a two-byte encoding of the value of the *i*-th (APP, KEY) such that 1 ≤ APP ≤ 127. ## Design rationale - The purpose of the PBKDF2 function is to thwart brute-force attacks in case the attacker is able to circumvent the PIN entry counter mechanism but does not have full access to the contents of the flash storage of the device, e.g. fault injection attacks. For an attacker that would be able to read the flash storage and obtain the salt, the PBKDF2 with 20000 iterations and a 4- to 9-digit PIN would not pose an obstacle. -- The reason why we propose to use a separate data encryption key rather than using the output of PBKDF2 directly to encrypt the sensitive entries is so that when the user decides to change their PIN, only the EDEK needs to be reencrypted, but the remaining entries do not need to be updated. +- The reason why we use a separate data encryption key rather than using the output of PBKDF2 directly to encrypt the sensitive entries is so that when the user decides to change their PIN, only the EDEK needs to be reencrypted, but the remaining entries do not need to be updated. -- We propose to use ChaCha20 for encryption, because as a stream cipher it has no padding overhead and its implementation is readily available in trezor-crypto. A possible alternative to using ChaCha20Poly1305 for DEK encryption is to use AES-CTR with HMAC in an encrypt-then-MAC scheme. A possible alternative to using ChaCha20 for encryption of other data entries is to use AES-XTS (XEX-based tweaked-codebook mode with ciphertext stealing), which was designed specifically for disk-encryption. The APP || KEY value would be used as the tweak. +- We se ChaCha20 for encryption, because as a stream cipher it has no padding overhead and its implementation is readily available in trezor-crypto. A possible alternative to using ChaCha20Poly1305 for DEK encryption is to use AES-CTR with HMAC in an encrypt-then-MAC scheme. A possible alternative to using ChaCha20 for encryption of other data entries is to use AES-XTS (XEX-based tweaked-codebook mode with ciphertext stealing), which was designed specifically for disk-encryption. The APP || KEY value would be used as the tweak. - Advantages of AES-XTS: - Does not require an initialization vector. - Ensures better diffusion than a stream cipher, which eliminates the above concerns about malleability and fault injection attacks. - Disadvantages of AES-XTS: - Not implemented in trezor-crypto. - Requires two keys of length at least 128 bits. + - A 32-bit PVC would be sufficient to verify the PIN value, since there would be less than a 1 in 4 chance that there exists a false PIN, which has the same PVC as the correct PIN. Nevertheless, we decided to go with a 64-bit PVC to achieve a larger security margin. The chance that there exists a false PIN, which has the same PVC as the correct PIN, then drops below 1 in 10^10. The existence of a false PIN does not appear to pose a security weakness, since the false PIN cannot be used to decrypt the protected entries. + - Instead of using separate IVs for each entry we considered using a single IV for the entire sector. Upon sector compaction a new IV would have to be generated and the encrypted data would have to be reencrypted under the new IV. A possible issue with this approach is that compaction cannot happen without the DEK, i.e. generally data could not be written to the flash storage without knowing the PIN. This property might not always be desirable. ## New measures for PIN entry counter protection -Our current implementation of the PIN entry counter is vulnerable to fault injection attacks. +The former implementation of the PIN entry counter was vulnerable to fault injection attacks. -Under the current implementation the PIN counter storage entry consists of 32 words initialized to 0xFFFFFFFF. The first non-zero word in this area is the current PIN failure counter. Before verifying the PIN the lowest bit with value 1 is set to 0, i.e. a value of FFFFFFFC indicates two PIN entries. Upon successful PIN entry, the word is set to 0x00000000, indicating that the next word is the PIN failure counter. Allegedly, by manipulating the voltage on the USB input an attacker can convince the device to read the PIN entry counter as 0xFFFFFFFF even if some of the bits have been set to 0. +Under the former implementation the PIN counter storage entry consisted of 32 words initialized to 0xFFFFFFFF. The first non-zero word in this area was the current PIN failure counter. Before verifying the PIN the lowest bit with value 1 was set to 0, i.e. a value of FFFFFFFC indicated two PIN entries. Upon successful PIN entry, the word was set to 0x00000000, indicating that the next word was the PIN failure counter. Allegedly, by manipulating the voltage on the USB input an attacker could convince the device to read the PIN entry counter as 0xFFFFFFFF even if some of the bits had been set to 0. ### Design goals @@ -140,31 +145,34 @@ Under the current implementation the PIN counter storage entry consists of 32 wo ### Proposal summary -Under the current implementation, for every unsuccessful PIN entry we discard one bit from the counter, while for every successful PIN entry we discard an entire word. In the new implementation we would like to optimize the counter operations for successful PIN entry. +Under the former implementation, for every unsuccessful PIN entry we discarded one bit from the counter, while for every successful PIN entry we discard an entire word. In the new implementation we optimize the counter operations for successful PIN entry. -The basic idea is that there will be two binary logs stored in the flash storage, e.g.: +The basic idea is that there are two binary logs stored in the flash storage, e.g.: ``` ...0001111111111111... pin_success_log ...0000001111111111... pin_entry_log ``` -Before every PIN verification the highest 1-bit in the pin_entry_log will be set to 0. If the verification succeeds, then the corresponding bit in the pin_success_log will also be set to 0. The example above shows the status of the logs when the last three PIN entries were not successful. +Before every PIN verification the highest 1-bit in the pin_entry_log is set to 0. If the verification succeeds, then the corresponding bit in the pin_success_log is also set to 0. The example above shows the status of the logs when the last three PIN entries were not successful. -In actual fact the logs will not be written to the flash storage exactly as shown above, but they will be stored in a form that should protect them against fault injection attacks. Only half of the stored bits will carry information, the other half will act as "guard bits". So a stored value ...001110... could look like ...0g0gg1g11g0g..., where g denotes a guard bit. The positions and the values of the guard bits will be determined by a guard key. The guard_key will be a randomly generated uint32 value stored as an entry in the flash memory in cleartext. The assumption behind this is that an attacker attempting to reset or decrement the PIN counter by a fault injection is not able to read the flash storage. However, the value of guard_key also needs to be protected against fault injection, so the set of valid guard_key values should be limited by some condition which is easy to verify, such as guard_key mod M == C, where M and C a suitably chosen constants. The constants should be chosen so that the binary representation of any valid guard_key value has Hamming weight between 8 and 24. +In actual fact the logs are not written to the flash storage exactly as shown above, but they are stored in a form that should protect them against fault injection attacks. Only half of the stored bits carry information, the other half acts as "guard bits". So a stored value `...001110...` could look like `...0g0gg1g11g0g...`, where g denotes a guard bit. The positions and the values of the guard bits are determined by a guard key. The guard_key is a randomly generated uint32 value stored as an entry in the flash memory in cleartext. The assumption behind this is that an attacker attempting to reset or decrement the PIN counter by a fault injection is not able to read the flash storage. However, the value of guard_key also needs to be protected against fault injection, so the set of valid guard_key values should be limited by some condition which is easy to verify, such as guard_key mod M == C, where M and C a suitably chosen constants. The constants should be chosen so that the binary representation of any valid guard_key value has Hamming weight between 8 and 24. These conditions are discussed below. ### Storage format -The PIN log will replace the current PIN_FAIL_KEY entry (APP = 0, KEY = 1). The DATA part of the entry will consist of 33 words (132 bytes, assuming 32-bit words): -guard_key (1 word), pin_success_log (16 words), pin_entry_log (16 words) +The PIN log has APP = 0 and KEY = 1. The DATA part of the entry consists of 33 words (132 bytes, assuming 32-bit words): -Each log will be stored in big-endian word order. The byte order of each word is platform dependent. +- guard_key (1 word) +- pin_success_log (16 words) +- pin_entry_log (16 words) + +Each log is stored in big-endian word order. The byte order of each word is platform dependent. ### Guard key validation The guard_key is said to be valid if the following three conditions hold true: -1. Each byte of the binary representation of the guard_key has a balanced number of zeros and ones at the positions corresponding to the guard values (that is those bits in the mask 0xAAAAAAAA) +1. Each byte of the binary representation of the guard_key has a balanced number of zeros and ones at the positions corresponding to the guard values (that is those bits in the mask 0xAAAAAAAA). 2. The guard_key binary representation does not contain a run of 5 (or more) zeros or ones. 3. The guard_key integer representation is congruent to 15 modulo 6311. @@ -193,9 +201,9 @@ int key_validity(uint32_t guard_key) The guard_key may be generated in the following way: -1. Generate a random integer r in such that 0 ≤ r ≤ 680552 with uniform probability. -2. Set r = r * 6311 + 15. -3. If key_validity(r) is not true go back to the step 1. +1. Generate a random integer *r* in such that 0 ≤ *r* ≤ 680552 with uniform probability. +2. Set *r* = *r* * 6311 + 15. +3. If *key_validity(r)* is not true go back to the step 1. Note that on average steps 1 to 3 are repeated about one hundred times. @@ -223,23 +231,24 @@ and the `y` bits to its corresponding complement: `(~guard_key) & LOW_MASK` -That ensures that only one 1 bit is present in each pair xy. The guard value is equal to the bits labelled "v" in the guard_key but only at the positions indicated by the guard_mask. The guard value is therefore equal to: +That ensures that only one 1 bit is present in each pair `xy`. The guard value is equal to the bits labelled `v` in the guard_key but only at the positions indicated by the guard_mask. The guard value is therefore equal to: ``` - --------- x bits mask -------- & -- guard_key -- + -------- x bits mask --------- & -- guard_key -- guard = (((guard_key & LOW_MASK) << 1) & guard_key) | ----- y bits mask ---- & - guard_key shifted to v bits (((~guard_key) & LOW_MASK) & (guard_key >> 1)) ``` ### Log initialization -Each log will be stored as 16 consecutive words each initialized to: + +Each log is stored as 16 consecutive words each initialized to: `guard | ~guard_mask` ### Removing and adding guard bits -After reading a word from the flash storage we will verify the format by checking the condition +After reading a word from the flash storage we verify the format by checking the condition: `(word & guard_mask) == guard` @@ -251,7 +260,7 @@ word = ((word >> 1) | word ) & LOW_MASK word = word | (word << 1) ``` -This operation replaces each guard bit with the value of its neighbouring bit, e.g. ...0g0gg1g11g0g… is converted to ...000011111100… Thus each non-guard bit is duplicated. +This operation replaces each guard bit with the value of its neighbouring bit, e.g. `…0g0gg1g11g0g…` is converted to `…000011111100…` Thus each non-guard bit is duplicated. The guard bits can be added back as follows: @@ -259,7 +268,7 @@ The guard bits can be added back as follows: ### Determining the number of PIN failures -Remove the guard bits from the words of the pin_entry_log using the operations described above and verify that the result has form 0*1* by checking the condition: +Remove the guard bits from the words of the pin_entry_log using the operations described above and verify that the result has form 0\*1\* by checking the condition: `word & (word + 1) == 0` diff --git a/docs/key-derivation.odg b/docs/key-derivation.odg new file mode 100644 index 0000000000000000000000000000000000000000..44d684d45d474bc195656eacc563c8266c8bb538 GIT binary patch literal 13948 zcmch;V|1n4wk|xAR4T66sIX$&wr$%^Dt0QiDzJmeW`uhx@+xy);jl`KVP41 z%r@S)&HfC|f&TO^BM$Nj2><{G0O)L3r7}RMddUF*!0+_&3Sen!Y3Sf$W2kFmV_~YV z>tJeaMeSr|KxM6KZ)#6vZDVLIKhUsQ!MQ$#ve~d%O#ut(BNPjR6g-b-3`DtU z0mX#+4*QAATgOL-ljQ?RH1fJ)fD~Mizh1JqV`1mWo&F1W`jK;PS{1v-A^<90r|g_^~+Qjrqwd|rK_8O z@Yr}s{H|TIEQwd#u!)(BnvdJ|+uIIIa}1oVe+IXSdC;UbG~o0ZOJ$wAZYMuThFo$s zqWQhA*R!nOF?=rRBFNOrw{VSUhK}qG17Fg!CNcB1fhWLn-}$JR95MD z3G1<(zT_v<9a>kEvAY&Ty?JI6yFn;E*i)m>V|)KwN0=hzP4n4W(h`TwRF!RCqyTTrhPW4Nhg21U#xx zw4iklGxS zR1Iw0?8!pmElS$qt-r>p=Ge_ z3kGMC=C&vHwoVpm=LYy9#b_Hx+_4O2ufpEZ<4DOlH{@5_HxwsS&SA}s-QnHcp$$an zU3cOq#U?pc^!D%zi*|XB!N64oAvA)YW8h{9 zzw)bXPnSim7Gt%S+q5uG=mtO@cgj23vD!j&4i`qU;aZ~@Db&>XI+{F`a`{XcwN!D< zEfV%qbF&2ryn9*+YQ)>4XPVRq4|X)di~Ov^&kmjod(wc3tf$eaqnG>Y#ZE4Bx^6Bp z4$j50Alx_8Zqdk!iK7fM*p7)f`~JC-*sC^lylg3kPmB+$KJ54q0XTl>6oSIPDn%&m zVs*T9bK)&{TbUs;_+sH0_PxiW`k3zhuV=!*14W?W8dO@{VCB>#+sN3Na9Pddt&ZQ@ zPTPkUoeDHCEkRPCZG7&EspC8He$Br7ex3A0Xf8Tg$J;Ex`>K$JqvqBwa8p}xHjX9I zPruVBt9;tqd7{e-GSKs`g9E!XnnQpvQ)sHD;FjK&n2p%#BQ(*O(i{eQ?;sq=`NPQX ziA)%`ux8^G;ZnGJiz*q&E6vwJczY$~rF~#!tMlv&@X&S%PfB1A@z1;SIKMC&!s9BQ zm(Lz<}tOtCf?rtpoUB_6rBwv4hJ=IVb;SDWA_N9UUOBo}q1v2g3UX+C zKRq#{7Ml?y&tI5?E-;%o)n&eAy34D1X-ZQs6FZce3G^a};(XMA1y-_897{qSCArJM z%Um@&IAaO1JVaW`N=G_QjD^vbp*Y2%TS?2iR2~~nKUE>E;|OQ$^eZ>M4^Ru|9TvlY z@=pJN1B}0ABEgL`ThBzdOGFD%E8>Dy{vrr)TAPBG@mhDlDYzFj&e%-)zPtOggj?LB)7l?VK<`TEx<5@MSYhzj5>K) zHuI%VF)wCX!gA>|t^)gnDh(f<>v`BjJ$KN#|NCxi)NSRfaTWuyr%c-ko6RBERezd7 zh$l@#+x`!^^+WXc+zj0z^oWceFlW~WfwAe?md5R#YQ(NP?8D_YyLG1%%Y|Uwo3P;v zN0R}X)vBkq3xySuLcQa83a+p)#aO0!p0TAgr{Y+3<5SJiT>0{H-YRJhv$9p$%cge* zs_<=@GT13g`|sijYx1Ur4|8fi@ff;^&$Hp1XSC{=6}%Faw{*>-yL!{yPPt4!=QVxp zoP;W6%^at1r6f(&ty>7&J`2Zl6`~W`RPVJ`x6pA85nHHnK8{-z)li(!zn|A^lxKD) ziPUC^d85IVF4qi8$)&ATd(E2`mJv6%c&%NQDy5-1M^zf?&@8$eo;GE_!c&3ou^3&g z*7q|NIYT7}UI}rVZ@f0i`83vkK^3Sh^=uV!lAz1L)?cY|8mYebU9C3N*4$8P)NGwf zE#H(u&1MR)f~xVTaF-@ zRuGcVaf##h>rK_c`Uv&m&&^jUu{bAXRrbX?qw%O8>rENxWY+E6rJ7d4zLS@2>Nvp& z6Yvvv`wnecT;S$dwAON~)tp^>FA;{G&2TX1U6h-u~geoG7GRfm;7-*kM@qQ5e2 z%Cg>Pq;T&ptkHjsA{7sQOm3MmxHRiUb{SuM&FPiLw`)=*S~2$M8!lc{=eArQmQ&VN za*XF`f?u6^gN4tMmTH#{r+%-YV)TBGqF_4eLV20V9KN>x9mKb#Na?TkZIJW)=Ypo< zGD|)+=r2jMj<#**&*&u%ycQ>6niQhL6mJ@tYtAv}AjJ5*KEKWg8z>jX;qDhCGl8&^ zfdY7(6n5zevU&U|p)M%W$AfxYj`Q9h54Ta>1m~5cPHqsPB2a}A5(yB?v7IZCyz2!` zDJRfNA>-Q*~=Y=B-+wa%xBq>5?WeMSZYcKA%CS z23Oh-zOlC>r8OhZl#+b2zx5DDlchy*pyHVhn>IN6q`(NP(M1O5$Ni+ua_H#GeC&ABtx6I4|bGu2XrLa9z z!r`+S)WyoBEEMd}yM>}(&)&Im?15n(;bvplk>#*Q*YjK?PX@YGnJT?sgj7_R;P-l+ zdRmxm-G>949_V+U6W$MaD)leyv?*X)KYfahLz1|@On48iyX@&uJlNt*C)Z4#h7#Wb zg4;L(_OfJFJCf`fKa+Mqd2fiZ@mYC`M9Bx?O+-|-N=9B_CLIPSBJ%OE& zUBkt1v|_5!@rpq|D%?y@sJsH%XU-4;>at5CVma1s(A}ZHDe-4_m1ZYaXOF^+@(<}I zp#brsE)A;D;0;qzu>!AwdN(@#zEnt99Ai~cbJ<2;aL5$LM;9jNf=qJ)jMM?V3{zOV zWg9eH5#)qN7Fr$Bk5`-uCVR&~o7>R3@83yqpCpTgfzluY2mB`<4F>4_Q)iGw*zrQFdfB2raIawH-WNuu*6 zbCx-Et|u#~?|5Hlzy@q$gD|})v1P{?i#OHLwtHvj0dkN(9Tkg55n(ymp=81-$YoYI z85JZ{e|q^7vbLnFiRc!)joX*HV^<;RiaFs_z()RXqHSZ|G=pNwgyJGMy0ha<;&#uH zV1(sGt^d~IXYH)5enb8RV!Ul^of`K-HHR$c0;qhYr`vSVIYO=s@b+SVwAZ2PBH@2%A0}^G}qh3_s##zYX&ETO+;8 z@G^_ov4GcU4PMtlxU@!>YS6;W~ zS|G^iTBZh{2|m0e^ue{%;ZkMOSij>O7ZQ+>9*=oL$2Xjjg|iM zMyO)ieVv>RNoS&6@X4I(0z~Y%Z18hr5H&)hf$*=~uA53nO$6IZLhK*M*Ovp|#WK(3 z)~`C=@41&|P^jd-8`THa_iG#j8C`u=J!xy+{h9qlRP9S0X+9Vt2dKyMF?X@|qNW-C zv`|{74N#Q*>6Y%uc?gbm0m0&r`J^`mqWSOF56I@aalzOF(T~S z3+*$HI{3#{>ek~5aWi(&SOT}dcSFB5<8d`$F_GA&k>1LIC`71J5eId+07p?;CO!fy zq+`v$!4IxHA2>_htHn4`?=Aj3oUv`~-DJDh&`K{oG@PMv9PJs8^m5f8+v<{$CNZtT zlf@rkX{RU+rdoz?CL#)kV;VKT6dWLM%@pj3^m8}_c@m?7%M12ed(E>|dWSDq4&4%g zC#WG?dygJ9p;tSWN*9tYND;oJ} z@%-HT5D65RJ2ICB$|C%Pf`+{N^R;)5y3u(lxCh=%1u3V}e3rCy0a9r#g|$$CjR`{S zG?|Hux4wX@9}PSiyAWbd3{7+vt?u5v#|3PWMN41MBRe`bgSf3y(;9`>1sB|`5?mY* z?w}Agcyghh1`sbd(5F(fnViXTNPd|EWl-pV5(_068fhM0`H0V16Yr*FDusgYKg8cE zxD80Nb4e9bqk88t;LkdU`2Dyg;bdER#90#!=L zvG3o%A6f-hUSc<+2GeV%@9*?=;oI8jV5fEx=K}mvp(Re?=yu~X&4pg1+pT113hY#v zZko9aA8tvJW2AyM=o(Kyca-fGe@;!#&PJV~wb6T;Qp>w?_S((NO+PR5w#nKR+PB** zY{Oy*;nJXdw5da-rzjTk`T`YVrXXSKi*>hu&+Xwc#r5*goI^<8L|B98%9VQt=%b#) zmLIaXs@`^q`*Ny!9W|}XGY_5TMry9qb)_XU&mjvWSfX3w+fAxk3tv` z^j-I`=9~*(RZhEhf>r(wJWIWd@I{E#&7hhzFY;TQg^>CiN#w}a_=Fc(s+~wQl^q5h z^B+~Yr3|@dFh2>PkFnqiUw>}@tW*%xR2J4V&8`3CpU3t^+!ByLR*9w`4Bd&45;E&e z1WoV-oGQX_ug?Dhb7}nw_@TM=B^UP?U#?{YdwIRz2;Jb9+WEmY4HKk_FUd@^kn#@l zgN`Y&xR|^uh&{Mxs?vO|v9D_1%-Ii9vjWChMi;~HItOMkT30_5GKFc#u z3yAsilGye0 zm=u|lg?%o@a-$%uVNkKJR_?Ck=UO@7W^Qv%6q9Q;ADr)J2=TBuFc-eHHkJoLbCAkK zt`}D~)wi$cNArnZ7YG?jr=~__FtU~>bIWil0tE_g1+%S)r_U)wbgXXDKi!$I!~LY!DQ|@yZYLw>wKjR&&82#TXSY+BL=e# z^ttiJs9zzLD(;#w9|onw^i=HdcGm794(zz)wmb)GYYQ7)D?^L_ zraZL2sps!1{`aN*UBB4aSsU9K+W$Z5`SowgGquz;HngYaGj*`kwXy$SR`z!z|NF}R zT@#HgtaTj>|Fc8;E0IsPKWy;7({C*W6GuxuD_v6yduoS2vQ#!!#=$aD!Z45+kRLyR z5fu@T0{}iO`v5>cILOC0q*=Kr002BMBcUJ&1O$YDfPjsSO-4pWOH0ei$;rpZCnhGQ zprD|xuCAk_V_~9iVrB1SVP$J;Ywzyq>1^ZW*?w1<{#=7oZ##3l+Z_9TXfA;2R#~9~KrG;1}f|78ep8>ld9C9vv4NlN=M`7aty+9{D3VA~-QB zJUKcbIXW~wDJ(87HZDFnJ}EgRE+*|~TuMrce@tdrQeIqQZd^)sN?LY$WTT^AZtR_EADU|$S!o*EYMb8ct;p%EDD1B<>T4<+tSuR7Deh{n z>1uBqYOfpYXqs%vpX#WdYHQpIN;pc2-%ThuOwB#ZPCU&?Jub*UFUq@Wtv{;n?(eMc z>uMY7YM$+>neJ+tA8J}2Ztnh&{*msXiQ&HP;laLF(j_zKO-*@#+4_snN;l zk?G}`fzIiX-l_4Cm9g&G$+5Mm-sPE*xw+Yy`K7s~)up-V)y0{$wYA}et?}iZk>#V= zUpuqw2g|FQ6Wb>X8~f86XTLUgm$!~qPtIqzE>`xg)()<=XL>j1hPD^SPZqilS4TFN zXEuK=9jwh>3{GE+uV1YWKF;?&E%skcF79lto$b#a@BF&jnY-FwzB^dj-r3pSJKR1z zJ>1(lIoLTlIoUhCJvh5My*NL)x;edmIDdG(I@!5AJ$&5Vc{;nkzu3RKI(fW4eR({; zxw*N%d%Aske!RKMoq&b0TZu|lNS;n#8m6(9R$wPXLvVjpCo%w_^rs$wr}MnCQn}4pyU(?sJMNoo zB}qv25ShI93d)@|9yz1g=2Yj-}?}su~?b?cfz`^m5;=o0X z39ddF#}-lJR6mL+;+8Pj1@-J0_M&CI7$tFV8*tjekf>GP(z`EEe1p2Gs<{kc)r)1= zq2=+jbrcM|3CSeYX%N^1wb^}TKLscaR;IbawvfH?XQrN7`X{!w^kOK?05svPHTuj} znkH3(>8svN9WxjQ0>4HBE?g(8ULI?g=m$ULTS;xlU!$OOqzbee>$Wzq9Q6Bg13bhqhNpJfVcBW>E%^J|n;r*a^s!gmq7f#o2gs(di1aTrfD;!>oJ zMRU2Lp9Rk>@n-2zHXa)j>E$dC6&X>Y0KJ$vHNikEwR9L^CEjPf0E%Rw4Kd13SjiAT zTy=1h?Z67!U_rVomANnrK&Fa3{ro&nKZsua_T3isPzTsGG&$*c_d@aK1+;qNWb zn8r`B*rq6RFAuGyBZ;fN(?jE`(1ei|=OyJ1S|6Y$CP&z< zv4V=QeMO_0@kl$B&S;fN`EeM`iZN9?_Z3QqgAu@hYE<3=?5*8|h1f!MYfU*Vbd(iX zFLE@SJ$ai!R8v6}Bvyrhq}jd9w~h<|Uzb$}<53F%23VE&huHyWG668a8z$d8DKYC} z)S!JNkOZe72L)uUpu9yIt1$s<3Q@awl>yRDu=b@tS+QxtVgL~ zQa7bDE==fb&aA^iyKNP+E9T-6B&eN2bedu(T;F?T`I3jn2i=UXM}|YqkuiZ2<+6LL zpj(>h!r~!Rovptg9WB=!7`P>_F3SKA78qSm&2cGy!Xtmyx&2k1z^s9rviDr^R@P+Y z5K`(a-*ZVSm>_Y{_EfgepnQ3=2uF@Z+cb)CHb(?yT=FxN12sO>l$4 zcCwn_zSdZycgwdEw*?yax-#C1Ymm_bN@rLW(Cm7~po!x#odMC7xD z1jtneI)ARr#0Sy2X3aU-)Zry7>+7yEW18KTHpkb%KY`3{^6J^%x`aP zF`83`P@7f-YXljA)i5x|_P*@;l?Iyvt3SFQj3LVtgGVzv=v3_$hmSW9p9ZN?7ir9k zy%DzZo|@|L=0L~$K3jCAl&PG$^q?a#&*7;^o@p24$TC;gEM|bE~SHj?WK(C|V@0uO`Qv z6lIt?UkMtXBHPY5^b*%@*IvA1o01lvBN|$f^6;=(`DvurTKqOv%^#xR-C0FSk+Ej9 zBtwK&dQH}bEHdrxQwS&HK^~R+`qYx|1eKHL$rE#T?r{!NX1asEt9C6 zgsGL;W?32(U~W7vIay;oju)u}H2bsALz|+YJZ7ax_=xY-+t_?q^7J-wWC&mX)V)VJ z!ZC&&_Q2fNa}1d0OEO2#7_B9zrUVb9Pf^XPA2hu*EI|$O3N|9am-=(H7F9&Z%&1ii z#*V-==r;F7cvpXF2ITlvq^Fsx8?~*i1QZ4ZuuP=XR&jp72`S5VdvvJ~075%9Up9dp zR|@*Vy`BVM+y;y$<2{c|!$)+27+X!rHD&_V*_MLn5)cVzH+1hV!44?&^|yL#K)r@k zfbtG+;w}yKR8Rf#E{|#}?D80HFCa&5S`1>N{^9S?95oD7Tl<)D7#$4sNWn`O{zAjd zjx;EoZqDeB9lD53J6}51BVHUT6ZIG5RQb1S8p$kpaxy zBzev;Us;w{IH-m81f|t>mA+;HR5^^DB@po>hYWBwKTQyLj(j^{`%IF~c2Sr`PS#Yn zH!MXk{mI)4$vJjsTRWV&!e82$O%FdPzi?+e*AZ1VC%np=WD6Gsu~869B}g)%n}>Y? zf=ac6jE=*e{FkoJQFg% z5X;u*k_0nbwygk*j-kiUcc6dy!QWib-Z65pgK`~H`C^8V4mtxduAdO)ZqNAoSkSPx zd-HtE-KJ+Mrq?Q_qG8B_szrK6N<}=$O0Asyow4kDyIvvTE}1Yol`_6o74Uxj%J@Ol)qPy}sk^cqwV~E%H84aq zaUV9(V?oKGQjp&6bIaJyzAjAI4eMF7ypodP!4abifYn{`qa6(seX7>w}zgTQ}=ldhnSZY9j0xE(?*f1 z>wL~;(_Vvy%8Y0Fk{8t|_$aCh8T}L%J;qFxnM0IKl{fV#>?R0Gg|qm@S&OMTGn$kC zZaP8XVv#$QJStUot_|5rs^bEQkDjjQ;>pC$0zr>PIK=Ql z`3p`9(-q#;#_8%YTZ6%MuKDa21TNLOZ0AU=~7aT)GBtQ0ihMG43#9*+YZwhYFBQUsebd77px;PYg;5iL3j*n_)>A!58Hx%cr&uqqWy_*XV{1qXjRGE zM7=JO0;DWLOFO9EdMcG)*5L6I?(;gA>W0ood^!mcVLewdJu2gRfY@HTLsJqZ`!dXbDO%O~pX4C}7mBR}t7BQTmGR zcO3%`pn&$}W>0G-C0QR_GUnC6m=7bS)BgO$E3Wu`18twbxfz-uu1#fNKlF=X&%qW) zNPA`Vxh-9;8Na8>6a%O9cYp6)R8Za3)i6|I&Uc@ zDR^%X_R32gwp6=`K0@EZE0(Ywl0LEep#B31h<@pGTdf@XJCWWP5w z5iSF|B_cVWEEa9xx|=0dSYNa6;v6~tVkJy2?hR?GxXuz-9R!jRY6YIO=7W=p4W};_=*<7#o6ecG# z)^^6I7D$F)l?j^%U9pGT3xUC)cD9`?VKD|r<%!s$2I%-fHHUs9A{B1ZU??k>6fv5x zhqMX8Xvf8rpV2*@T1vdsm-|C!-$ab6H1=xa{fAgncahM{J3Xs#u=o~USmZ=4*Cy^C|k0BiUQjWnX5-dj1 z+QNikx#dATb>xXY*s%dx3@0YK6p`!3wNowY9$I8{H;-%~q?a9Bjm;ET^j0XEUh1VO z`F_9tKKo@Kdg~$eC^q_6jtNZM^89|L_d05z1)!?^6^P&uW+k3G z_mIFQDBZ_z8NZcL3Vi^@e}>=0iNT-mbf5UgH_T>!$!7oxz;^ z+c7_hTicwFzMAl8W~=1}E(>)7nR;hwf*-YM+m?hxYn7MLu za8e9I*(zB?JMH`3_R|uvoZ4tQt?V{wLVwd>$m$`D=9IzEKaONUVaKnBQ#TMStPnCX zuMS$EUTyUo9@G~b^?8~pmLi1_4t>i((A0t#x!gTZ9m=qyc*M*#!yuAU`f*3(i(`a8 zkhEig?l4Tv;^cR_%$Ms#(6UTV$xF@Hf%Ya7x1GK7E zJfiMZNOa|oDSe#<<{at9b2QXKw+eW<+XC$ZKaLrfjhQrEoO_Q6u0ng}hT0)qET5PG zzEzI8gJpd+Yf79JgfPksEV7f^W^?M5J;x)Oofx+SF3ZqlFanTombUJBOmlQ^x(fHZ zqu!$H_h91{y_s^|+@nqRTqd2_mI)QJg+hbtO`2Y_$mPcQRE{_(8iAbB^q(U#I#Oo) zd^uBFRmzF;sp|wY-iM7kQ}=+5lIHZ+i_;rh1p8(fZ}QmLVdZNIHX(Cr^{{*epO|IFrN4NvWx?vaayn*=lunso>k%(! z13XD1m0W=%A4hB$2H5~ODV#okXBLG&W3PEcX(R?K^s&W+byw0#vTS_e%c{!uG~&+Y zIK5vUg`-n|R0M6cZr2478~WxFu{lDuu|yg21zn#FXxd;Fe~W1w+-A@Q#ArsciE|M>s#AF?`t)LIAt zz?%0D{^Rdr5RgC4dXj<)yp*C+Le!SJR;EUV_W$zEE0Y&D>!E>L-A58~6Sq_n>>bLU zM9c+~*^Q>h4fp5jYVxo|B&H&Q<9DJTJ@DAeTFr80RGJJH_mXc_&!qXWkpPc9C z-tLzg=jlf^Q^cvS5SRoDVu^^0UqhS4MFmHk@swYsM5~p7J-)O<)d{I{lzE(`xs+LW z1)t0=z9!=7Q2#rV|zheyk6hYvBk2v^G&A;+wzdbbn6yA^7^A~^3KNSCt z4Es$N{V8*(|1VPQ-#hA0O#t9Gt@fwDevmZ(NzeV2Wc#1u2>%VvUrD$BDUR3Q;QW<@ z`)8crY}238@HaSrl5+oy^6&k8`Zp;5PSX7|(r=pXPa#JCul@XANV|Uq`}f8f{0-Qj zB;NlNCHZeq{v`GO9pyi1y+0c^`GN9JB;Ows`j3C!UsufEci=ze@Y`Q+#Q&-H*EQhx gditl#(fq^eDkBd1;VumTz({eJrY0PI{MX8-^I literal 0 HcmV?d00001 diff --git a/docs/key-derivation.svg b/docs/key-derivation.svg new file mode 100644 index 0000000000..1408faf65d --- /dev/null +++ b/docs/key-derivation.svg @@ -0,0 +1,411 @@ + +image/svg+xmlSALT +PVC +EDEK +32b +256b +64b +PBKDF2 +PIN ++ hardware salt +KEIV +KEK +256b +96b +ChaCha20Poly1305 +iv +cipher +text +PVC’ +SAK +128b +64b +first 64b of MAC +plain text +Flash +key +ESAK +128b +DEK +256b + \ No newline at end of file