One thing I have observed when giving security advice (and having the street cred to do so): people don’t believe it. You tell them no, really 2+2 is not 5, her

One thing I have observed when giving security advice (and having the street cred to do so): people don’t believe it. You tell them no, really 2+2 is not 5, here’s the Peano arithmetic to prove it (2+2 = 1+3 = 0+4 = 4), and they don’t believe you. Real example, I was working on TPM provisioning once. There was something fishy about the process: though they ostensibly wanted a secure channel between the provider and the TPM, the connection procedure didn’t properly authenticate the TPM. It could be replaced by a fake or emulated TPM, the provider would be none the wiser. Not too big a deal (it all happens inside the factory), but still worth pointing out. Anyway, my team lead did not believe me. Fast forward a number of weeks (the TPM is a freaking mess, I was slow), most of the provisioning was done, secure channel and all, the whole procedure worked without a hitch… on an emulated TPM. Told you so: we need to validate the public key shown in the certificate the TPM provides, else it could come from any manufacturer. Anyway, I had working code to prove my case, and my team lead still did not believe me. Me, the guy who wrote a cryptographic library, and was put to work on the TPM precisely because of that expertise. I had to escalate to the security guy on a meeting, and he believe me. Probably because he actually knew his shit. So at last, I was allowed to fix the bug. The lesson I draw from that is that demonstrating a security exploit is freaking important. It’s not enough to point out the bridge isn’t finished, people need to see a car falling down to its doom.