Security notes / Unsorted

Security related stuff. Linux - PAM notes · SELinux Securing services Public key encryption; SSL and TLS SSH: tunnels, X forwarding · keypair logins · SSH jails · loose notes · agent Apache config and .htaccess - security A little more practical security for the everyday person not-so-formal notes Ingredients that might be useful to know - MFA / 2FA · One-Time Passwords; also, authenticators More techincal waffling Message signing notes · Hashing notes · Auth - identity and auth notes Encryption - Encryption notes · public key encryption notes · data-at-rest encryption ·pre-boot authentication · encrypted connections Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted

✎ 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.

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?

"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.

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.

See also

• http://en.wikipedia.org/wiki/Trusted_Platform_Module

Pre-boot authentication

https://en.wikipedia.org/wiki/Pre-boot_authentication

JSON Web Signature, Encryption, Tokens

✎ 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.

GSSAPI notes

GSSAPI is a IETF standard to make it easier for various software to do various strong auth, e.g. Kerberos.

It also allows various other auth schemes to be plugged into it.

Which also makes it potentially interesting for SSO setups within an organisation.

(not unlike SASL, which can include GSSAPI)

It's used by things like OpenSSH,

NaCl

There are two security related things called NaCl - which are completely unrelated to each other.

(There are also other things called salt, like automation software Salt (a.k.a. Saltstack)

Side note: Asymmetric v.s. symmetric keys

Simpler systems had symmetric keys, meaning that the encoding and decoding key was the same.

This allows encryption in both ways -- and that both parties have to trust each other mutually.

You have to trust neither will accidentally or purposefully leak the key, because that key means all possible abilities including

reading received encrypted data from, current or past

imitating the other side's data

That's usually fine between two parties, but sharing the same key between more than two is as weak as the weakest link. Again,

reading all parties' encrypted data from, current or past

imitating all parties involved

This is arguably the largest problem that public-private key systems target (there are other upsides):

given the public key of someone's (public,private) keypair, it is nearly impossible to calculate the private one

ideally even with any number of encrypted messages

...which is why it isn't a problem to hand the public ones out.