Security notes - encryption-supporting functionality: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
|||
| (19 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{#addbodyclass:tag_tech}} | |||
{{#addbodyclass:tag_security}} | |||
{{SecurityRelated}} | |||
=Terminology= | |||
==Trusted Execution Environment (TEE)== | |||
<!-- | |||
A TEE (Trusted Execution Environment) is ''in theory'' roughly what it says on the can: | |||
an environment in which sensitive things can run, separate from the rest of what is happening, | |||
so is preferred for the security-sensitive operations (that often makes up a small subset of all things being executed), | |||
at least ''reducing'' the amount of time that sensitive data is kept in potentially more snoopable places. | |||
There are varied implementations of idea idea, and people's conceptions vary along. | |||
: It is ''generally'' understood as solutions where that execution is a different part of the 'main' CPU's work (plus OS awareness to actually ''use'' that properly). | |||
: ...but some will argue that some sofware-only solutions are also meaningful. | |||
: sometimes, the TEE is the only thing that can access ''all'' of the hardware, and everything else, including the OS, is restricted by the TEE | |||
Note that TEEs do not ''necessarily'' come with a secure place to store things like keys. | |||
Some implementations combine this idea in one solution, others do not. | |||
Even if they do not, TEE may still a better place to keep those keys while in active use (than main RAM). | |||
The wider concept of "execution that other execution cannot touch" is arguably a gliding scale, | |||
as things like SGX and SEV aren't designed to be purely separate - they also require the system to guarantee that they get some RAM that others cannot touch. | |||
"Why not everything?" | |||
Various TEEs have multiple things going on in them, separated from each other. | |||
So why not do it with everything, or make it a default you can give up? | |||
Performance - | |||
Management - in generally, a lot of things have to communicate. | |||
If all of those need to be administered, you run either into really annoying levels of admin, | |||
a sort of blanket yeah-sure attitude, | |||
or only coarse-grained. | |||
(SELinux might be an analogue here - a few use it precisely, many just sort of turn it off) | |||
--> | |||
==Keystore== | |||
<!-- | |||
It turns out that it's handy to have a place to keep keys, that aren't | |||
* on disk, where it can probably be read off while the computer is running | |||
* in RAM, where it can probably be read off while the computer is running | |||
--> | |||
==Also== | |||
<!-- | |||
Phones are ahead of most PCs in terms of integrating lower-level hardware to higher-level operations, | |||
in part just because it has APIs for hardware that is often there. | |||
like the ability to authenticate a signature with a fingerprint, etc. | |||
DRM schemes that ''really'' keeps all possible users and devs out basically need to be supported at hardware level. | |||
--> | |||
=Platform: PC / x86= | |||
==AES instructions== | |||
<!-- | |||
This is primarily about increases speed of certain encryption, | |||
and was once arguably more about inviting people to do full-disk encryption by ensuring it would be power-cheap and fast, rather than slow down ''everything'' and be a battery drain. | |||
AES instructions (rather than an implementation in plain x86 instruction) may also lessen the likeliness that certain [[side channel attacks]] will be useful to discovering keys or data. | |||
Beyond that, it does not store anything, keep anything, or isolate anything. | |||
https://en.wikipedia.org/wiki/AES_instruction_set | |||
--> | |||
==TEE and runtime protection== | |||
<!-- | |||
Intel: | |||
* Trusted Execution Technology (TXT) | |||
* SGX | |||
AMD: | |||
* AMD Platform Security Processor (PSP), officially known as AMD Secure Technology=== | |||
* SEV | |||
ARM: | |||
* TrustZone | |||
SGX is a trusted execution environment that allows runtime definition of private regions of RAM -- sort of like [[protected memory]], but more fine grained. | |||
...and more adapted to these virtual-machine days. | |||
These enclaves can be encrypted transparently by the CPU, meaning that they should be opaque to other processes and, ''in theory'', a malicious hypervisor. | |||
SGX is Intel. | |||
SEV (and SME) AMD thing. | |||
Each has different features/promises to start with. | |||
Each is also currently broken in their own ways - | |||
different implementation weaknesses, | |||
but it's not an apples-to-apples comparison | |||
in that how broken it ''really'' is to you depends on your threat model. | |||
Each still increases the amount of effort, | |||
and probably increases the amount of audit trial of attacks, | |||
and the next iteration of both is likely to be better. | |||
(and there's always people pointing out [[side-channel attacks]], | |||
but that is another threat model that is exceptional to many) | |||
Uninformed copy-paste, but it seems part of the problem is that when you want to avoid cloud machines peeking into your VMs, | |||
then the OS has to assume ''all'' hardware is malicious, which was never a threat model before, | |||
and a costly one to active protect against. | |||
https://en.wikipedia.org/wiki/Software_Guard_Extensions | |||
https://www.amd.com/en/developer/sev.html | |||
--> | |||
==TPM== | ==TPM== | ||
{{stub}} | {{stub}} | ||
| Line 411: | Line 565: | ||
* http://en.wikipedia.org/wiki/Trusted_Platform_Module | * http://en.wikipedia.org/wiki/Trusted_Platform_Module | ||
=Platform: Apple= | |||
==Apple Secure Enclave== | ==Apple Secure Enclave== | ||
| Line 428: | Line 581: | ||
--> | --> | ||
= | |||
=Platform: Android= | |||
<!-- | <!-- | ||
Verified boot - from hardware-protected root of trust, to the bootloader, to the boot partition | |||
The system and applications effectively run in their own VMs (Dalvik), | |||
Android (build on linux) uses SELinux | |||
hardware-backed keystore | |||
==TrustZone== | |||
[[Cortex-A]]/ARMv6KZ and later CPUs is basically a ''virtual'' processors or two (with access control). | |||
It's not quite the same as a separate core dedicated to this, but a simpler/cheaper solution. | |||
TrustZone | TrustZone is a good basis for a TEE | ||
What exactly it is used for varies. For example | |||
* Samsung Knox is | |||
--> | |||
=Unsorted= | |||
<!-- | |||
ARM has Trustzone and CryptoCell | |||
https:// | https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Fcryptocell.html | ||
https://www. | https://www.linkedin.com/advice/1/how-does-arm-cryptocell-technology-protect-data | ||
--> | --> | ||
Latest revision as of 11:31, 24 April 2024
| Security related stuff.
Securing services
Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted |
Terminology
Trusted Execution Environment (TEE)
Keystore
Also
Platform: PC / x86
AES instructions
TEE and runtime protection
TPM
✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.
What is it?
It's a hardware module that assists a few security needs
Part of its job is just to be separate, because that allows it to do some things with more secrecy than is easy to guarantee otherwise -- if used well, that is. And with footnotes (separation is also potential attack surface)
For some other needs it's more of a coprocessor thing, which doesn't always make much difference
Physically, TPM started as a clearly separate extra chip/module, that might be built into laptops (fairly common in business laptops), and for PC motherboards started as a plug-in module that was originally very optional -- and now, years later, Microsoft is pushing very hard on the concept, in that they refuse to run Windows 11 if it's not there or it's an older version[1].
Integrated?
These days, you also find TPM is integrated into CPUs (Intel calls it PTT, AMD calls it fTPM).
This is functionally similar to a separate TPM - it has its own storage, it can't be altered, only talked to via the same specific protocol.
Upsides
- saves having to deal with one more component
- and helps against some physical attacks
Arguables:
- it's possible that some attacks might be possible due to being integrated.
- Yes, it's isolated by a communication channel - that was part of the point - and TPM(1) communication is more easily sniffed if it's an exposed trace because that is itself unencrypted
- yet I wouldn't be surprised if there are side-channel attacks due to being on the same silicon.
Downsides:
- it is now harder to upgrade the CPU (rarely a thing in laptops, but surely so in desktops)
What does it do?
Being part of a larger idea, the TPM is a different thing to different people/needs.
It should also be note that it only makes attack surface smaller when used well.
Used poorly it changes very little,
and there is also the concept of blind trust leading to riskier behaviour.
(I'm still waiting for the day that more than a few percent of people start using GPG in an actually secure way, and that's twenty years old)
More technically, it e.g.
- helps store some keys,
- can create derived keys without revealing the original
- can do certain encryption/decryption for you
- may let you mark keys as "never allow these keys to be copied out" - which effectively ties certain keys to specific TPM hardware permanently
That
- may makes it harder to steal certain keys,
- may force us to use mechanisms that use derived keys rather than the master key,
- may mean there are some cases where you can use a key it stored without every transporting it out
- you might e.g. message signing (to prove you have a key) without ever having that key in RAM
- may let you tie certain uses to specific hardware (for better and worse)
- great for a select few uses, and alleviates certain physical attacks, because now only a single piece of hardware can do a thing
- complete show stoppers for others
- and a potentially risky tradeoff for some others yet - for example, you can force an encrypted drive to only work on the computer you encrypted it on. And if ever separated, you can basically never read that data again.
- you can prevent running boot code that wasn't previously approved
- as protection against malware that alters the boot
- again, with footnotes. Like - who does the approving?
On secure boot
"Can't detect TPM device"
Means the BIOS knows that you can plug in a TPM module, and is looking for it (configured to do so, or always does), and doesn't find one.
So tell it not to look for one (if you can), plug one in, or ignore this message. It's often under a header named something like 'Trusted Computing'
Some BIOSes will always look for it(verify), in which case you can just ignore the message.
More acronyms
What does TPM not (necessarily) protect?
TPM versus TPM2
Use and criticism, strengths and weaknesses
✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.