
Hardware Security (2017) - charlysl
https://scl.engr.uconn.edu/courses/ece4451/hs.php
======
blattimwind
_Hardware security_ nowadays almost always means "security implemented in
software that you aren't supposed to be able to tamper with".

~~~
ecesena
What I learned recently is that, at least in the open source world:

1) there is a very tiny number of mcu that you can use without NDA, and thus
there's little choice and you often have to trade off between features

2) having crypto in hardware reduces exportability and thus increases cost

For example, in making Solo (open source security key) [1], we were planning
to use NRF or SAM L11 chips, but gave up because of power consumption or flash
available. We ended up with STM32L4, and we had to go for L432 that doesn't
have AES in hw because it's cheaper and easier to find than the L442 with AES.

Conor recently spoke about this at Shmoocon 2019: [2].

[1] [https://solokeys.com](https://solokeys.com)

[2] [https://youtu.be/fVgUwHr2RUU](https://youtu.be/fVgUwHr2RUU)

~~~
dcbadacd
What was wrong with nRF52840?

Any plans on integrating things like GPG features (GPG/SSH key storage)?

~~~
ecesena
NRF consumes too much for powering it via NFC.

GPG/SSH are in progress.

------
mettamage
In my hardware security course we were recreating state of the art cache side
channel and rowhammer attacks (at the Vrije Universiteit Amsterdam, the final
project was to reimplement an attack published by the VUSec group).

They don't seem to be quite prevalent here, I wonder what gives.

------
godelmachine
No required reading for the following has been mentioned there, while
everything else has. If anyone has anything interesting required reading in
mind for the following 5 items, please contribute.

1) Application layer

2) Life cycle of an SGX enclave

3) Review session

4) Power side channel

5) Kleptography

