Git-Mirrors/tillitis-key
1
0
Fork 0
mirror of https://github.com/tillitis/tillitis-key1.git synced 2024-12-25 07:29:25 -05:00
Code Issues Packages Projects Releases Wiki Activity

Doc: move implementation details of RAM scrambling to RAM core

Browse Source
This commit is contained in:
Daniel Jobson 2024-11-20 15:36:27 +01:00
parent de8fcb8768
commit 1941a22007
No known key found for this signature in database
GPG Key ID: 3707A9DBF4BB8F1A
2 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
hw/application_fpga/README.md
View File

@ -75,7 +75,10 @@ The memory is cleared by firmware before an application is loaded.
The application RAM is available to use by firmware and applications.
MC: Is the scrambling here now?
The RAM core also implements (from the view of the CPU) transparent
RAM address and data scrambling. This scrambling is applied to make it
harder to extract application and application data from a memory dump
directly from the memory cores.
## `rom`
@ -132,21 +135,7 @@ should make it infeasible to improve asset extraction by observing
multiple memory dumps from the same TKey device. The attack should
also not directly scale to multiple TKey devices.
The memory protection is based on two separate mechanisms:
1. Address randomisation
2. Address dependent data randomization
The address randomization is implemented by XORing the CPU address
with the contents of the ADDR\_RAM\_ADDR\_RAND register in the tk1
core. The result is used as the RAM address
The data randomization is implemented by XORing the data written to the
RAM with the contents of the ADDR\_RAM\_DATA\_RAND register in the tk1
core as well as XORing with the CPU address. This means that the same
data written to two different addresses will be scrambled differently.
The same pair or XOR operations is also performed on the data read out
from the RAM.
The RAM address and data scrambling is done in de RAM core.
The memory protection is setup by the firmware. Access to the memory
protection controls is disabled for applications. Before the memory
@ -168,11 +157,6 @@ setup the memory protection:
6. Receive the application sent from the client and write it in
sequence into RAM.
Future TKey devices may implement a more secure ASLR mechanism, and
use real encryption (for example PRINCE) for memory content
protection. From the application point of view such a change will be
transparent.
## `touch_sense`
Provide touch sensor events to software.

16
hw/application_fpga/core/ram/README.md
View File

@ -23,6 +23,22 @@ ram_data_rand inputs as seeds for the scrambling mechanism. When data
is read out it is descrambled before sent out on the read_data output
port. The scrambling functionality does not add latency.
The memory protection is based on two separate mechanisms:
1. Address randomisation
2. Address dependent data randomization
The address randomization is implemented by XORing the RAM address
with the contents of the ADDR\_RAM\_ADDR\_RAND register in the tk1
core. The result is used as the RAM address.
The data randomization is implemented by XORing the data written to
the RAM with the contents of the ADDR\_RAM\_DATA\_RAND register in the
tk1 core as well as XORing with the CPU address. This means that the
same data written to two different addresses will be scrambled
differently. The same pair or XOR operations is also performed on the
data read out from the RAM.
Note: the scrambling mechanism is NOT a cryptographically secure
function. Even if it was, a 32 bit key would be too short to add any
security.