# M2354(TU)

## Trustzone intro
### Memory
1. Secure World & Non Secure World
2. Only secure code can access secure memory
3. Secure code can access non-secure memory
4. Non-secure code can access secure memory through Non-secure callable
5. Using Address bit 28 to partition secure and non-secure
-> 0 indicate secure and 1 indicate non-secure
### SAU
1. Programmable, dynamic partitioning address
2. Either NS or NSC

### IDAU
1. Not programmable, static partitioning address

### KPROM
1. Used to store secure user keys and key retry limitation
2. If enabled, LDROM, APROM, KPROM will be protected by secure user key

### XOM
1. Execution only rigion, data access will be denied
2. Defined in APROM

### ARLOCK & SCRLOCK
1. ARLOCK can protect LDROM and entire APROM
2. SCRLOCK can protect LDROM and only secure partition of APROM


## Power Management
### Different Power Mode
1. Normal mode
2. Idle mode
3. Power-down mode
- PD
- FWPD
- LLPD
- ULLPD

### Normal mode
- VDD & VSS supply for digital logic

### Idle mode
- CPU clock is disabled
- The fastest mode to return to normal mode

### Power Down mode
- PD mode disabled CPU, HXT, HIRC clock and DCDC. LDO is in low power mode.
- FWPD mode disabled same part as PD mode but LDO doesn't in low power mode. Therefore it's faster to wake up.
- LLPD and ULLPD moreover drops LDO's voltage.

### Standby PD mode
- Some logics and memories are disabled.
- System SRAM and Bank0 data can be retained.

### Deep PD mode
- Most logics and memories are disabled.
- It is the mode that cost the longest wake-up time.



## Block diagram of M2354

### Memory
#### RAM (Storing short time, fast to access)
#### ROM (Storing long time, have writing limit)
- APROM: Storing application, IDE info...
- LDROM: Storing bootloader.

### AHB & APB
- AHB: High transmittion bus.
- APB: Low power, low cost transmittion bus.

### Power control

void CLK_SetPowerDownMode(uint32_t u32PDMode)
{
     CLK->PMUCTL = (CLK->PMUCTL & (~CLK_PMUCTL_PDMSEL_Msk)) | (u32PDMode);
}


### Security

## Sentry

### UART
- Use two lines(Tx/Rx) to communicate, clock line is not needed.
- Some similar function like I^2^C or SPI
- The data smaple frequency have to be the same to keep data syncronize.



### Non-Secure
1. Open UART
2. Wait for processing ticket
3. Pass the ticket to secure world to verify whether it's a valid ticket

### Seccure
1. Ticket-moduel.c & bridge.c
2. Use AES to encode ticket
3. Verify Signature by SHAHASH

## Sentry Architecture
### Ureka
- Owner-managed access control protocol
#### Initialization Ticket
- Ticket for manufacturer.
#### Query Ticket
- Ticket to inquire public key of device or Sentry
#### Ownership Transfer Ticket
- Ticket to switch ownership.
#### Access Permission Ticket
- Ticket released by device owner to authorize a guest to access the device.

### Secure Boot
- Using hash value or digital signature to ensure the untampered load-in code is safe before loading into device. Once loaded, the control will be transfered, otherwise the system will halt.

### Hardware
#### IDAU & SAU
- Related to secure and non-secure memory regions.
#### SCU
- Configure peripherals of secure and non-secure platform.
#### FMC
- Isolate secure flash memory region.
#### Hardware Crypto Accel.
- Utilize for ECC, AES, SHA etc. Also reduces the size of access control code.
#### Key Store
- Manage private and public keys except the session key, securing SRAM, flash mem. , and OTP mem.
#### TRNG
- Used to generate private keyof the Sentry's key pair.

### SoftWare
#### Secure Bootloader
- Integrated into ROM, the first program operates after the device boots up.
#### Sentry loader
- Verified and executed by Secure Bootloader
- It is used to verify the Communication Proxy and Ticket Module
#### Ticket Module
- Controll the above program, prevent Communication Proxy from accesing them.
- Securely storing and managing keys related to Ureka protocol.
- Perform tasks based on received ticket type.
- Verifying owner's signature on the ticket and user's identity.
- Passing the command of the verified ticket to secure system to advance performing the operation.
- Creating session for encryption data transmission.
#### Communication Proxy
- Receving authorized tickets from users.
- Runs in non-secure state.
- Controls several communication hardware e.g. Bluetooth, UART ect.
- Only accept known ticket type, otherwise ignore.

### Flow
1. Secure Bootloader is loaded in the XOM from the Sentry's ROM.
2. Secure Bootloader verifies the Sentry Loader by calculating hash value. Them the value be further verified through ECDSA and compared with the signature.
3. The Sentry loader also use the same method to verify the Ticket Module and Communication proxy. If the process seccess, the control transfered to the Ticket Module.
4. Ticket Module initiates, and transfer the control to communication proxy and waiting for incoming data.
- Initialization ticket
1. The ticket module check whether the Sentry preposessor is in the raw state.
2. If true, the Ticket Module use TRNG to generate Sentry's private key (internal identity); use crypto accel. to derive ECC public key (external identity). These key pairs will stored in Key Store's flash mem. The public key on the Initialization Ticket will alos be stored in Key Store as the owner's key.
- Ownership Transfer Ticket
1. The ticket module use the original owner's key to verify the signature on the ticket.
2. If true, the buyer's public key will be stored in Key Store's flash mem. and registered as the new owner, replacing the old owner's key.
- Access Permission Ticket
1. The ticket module use the signature on the ticket to verify the owner's key.
2. Sentry performs challenge-reponse authentication using ECC signature to verify the user's identity.
3. If seccess, the command will be sent to protected system and perform the operation. E.g. Viewing the access log, the Sentry will create a secure session which allows the data transmitted secure through the symmetric-key encryption, AES.


## How does it works
1. Communication proxy
- Hackers inject spam code into communication proxy, trying to modify the memory of the Ticket Module.
* By Trustzone's memory design, it will block such operation.
- Hackers try to inject code through buffer overflow approach
* Ticket Module only accept specific type ticket.
- Hackers may try to modify code in flash memory
* FMC will stop it.
- Implement code when booting system
* Secure Boot will prevent it.
- To sum up, if hackers only control the communication proxy, the system should be safe due to trustzone architecture.

2. Peripherals
- Since all the peripherals run in secure state except the external communication devices, they will be secure by trustzone.

3. Keys
- Key Store plays an important roll in this part.
- Key store is strictly prohibited from non-secure program.
- Public keys are stored in OPT memory
- Private keys are stored in secure memory

4. Communication session
- Ownership Transfer Ticket & Access Permission Ticket
* Requires keys which are protected by Key Store