Schneier on Security

Thoth • November 7, 2014 9:27 PM

@Nick P
Use a Yubikey. (https://www.yubico.com)

That should handle the 2FA part.

I did attempt to suggest Yubico to allow their Yubikey to store a small secure cache of critical passwords and act as a Hardware Security Password Device besides being a tamper resistance OTP device but they do not seem to be interested (due to high costs as they claim).

For storing secrets on smartcards and so on, use the smartcard as a HSM to protect the black key sitting on the device. The smartcard decrypts the black key into red key (encrypted passwords that have been secured with smartcard private key) and it should be fine. The only thing is, how can we trust those smartcards and smartcard based HSM out there 🙂 . Of course if the bottom line is not really about HSA resistance but more on script kiddy resistance and hacker wannabes, those should be fine. Once it hits the HSA resistance (CC EAL 7+) level, then the story changes into a high assurance design.

Thoth • November 8, 2014 4:37 AM

@Nick P
Most of the ideas for custom built hardware I give here are based on the easy to access Raspberry Pi board which runs an ARM processor. It seems like seL4 may have a chance of booting onto a RPi and there are people trying to boot seL4 onto RPi. So far I have not heard any official success yet but who knows if someone actually got something running already.

seL4 has a generic ARM page: http://sel4.systems/Hardware/General/

I have a RPi myself but all I need is to figure out how to interpret the above link into actual steps and procedures to load the seL4 onto an empty SD card to boot the RPi into seL4 CC EAL7+ kernel.

If that succeeds, we might have an open hardware (RPi) with a CC EAL 7+ kernel (seL4) and using a soldering iron to dislodge unnecessary hardware parts that might allow covert channel attacks (need to figure out what to detach from the board). Generally the board is pretty much fine because you have to actually make an effort to attach the Ethernet cable, audio jacks and so forth onto the board otherwise if you seal the board into a properly made external casing and make use of the GPIO pins to allow a wiping function with pressure switches to detect tamper on the casing, it should easily clear quite a few levels of CC EAL ? Adding a faraday’s cage kind of mesh for EMSEC protection might even put it to FIPS 140-2 Level 4. Also mounting some form of temperature detection, movement detection and humidity detection further increases it’s chances of reaching a very high assurance rating and FIPS level 4.

It would be nice to see a general purpose board turn into a high assurance and high FIPS machine 😀 .

Any ideas ?

Thoth • November 8, 2014 8:32 PM

@Rick
What Clive Robinson meant was TOR, despite knowing it is vulnerable to TA, chose to bury the issue. Such behaviours for running an open source security software is one of the most detrimental attitudes which shows they do not care too much in a sense. Nothing personal against those TOR guys since I do not know any of them but the attitude of pushing or burying problems in a security software can lead to more problems.

What is high assurance ? All round, well worked out life cycle and implementation. A guarantee of the security implementations (practical) and formalization of definitions (academic) where the security proofs are highly robust in face of highly adverse conditions. This includes TA, MitM, tampering with internals and many such.

Nick P, Clive Robinson and myself have posted a whole sleuth of stuff on assurance mechanisms which Nick P and Clive Robinson posted the most and probably the best stuff around here.

You can say that TOR is useful for up to medium strength adversary (MSA) or even low strength adversary (LSA) entities since it does not consider much of TA and covert channels of sorts. The machine it runs on is not guaranteed at all thus endpoint security is terrifically weak (quote Ed Snowden).

I agree with the view of education as I am also struggling very very hard to educate people inside the ITSec industry in my country to look into high assurance security instead of those pretty useless homebrew crypto that have very little effect against even an LSA. You could run a replay attack or swap their certificates out and I can tell you have their supposed security stuff goes insecure. They think crypto is magical in properties but they do not consider other impacts. They are also extremely complacent of their personal security and leaks out their PIIs on a frequent basis despute working in the ITSec industry and most of the working in the ITSec industry have very weak backgrounds. All they know are the magical properties of mechanisms but not how they work and when details are given and shown how to break their concepts, they whine loudly and become irritable and claim that I am too paranoid for my own good 🙂 .

So what is left if TOR is considered vulnerable ? We need to think along the line of a layered approach just like how TOR was designed. Like an onion. We decide what level of protection we want for different communication and assign them to different mechanisms. The most you can use TOR is up to the level of MSA. If you don’t want a high strength adversary (HSA), then you might want to start looking into Tinfoil Chat (TFC) which you can find in (https://github.com/maqp/tfc) but I would warn you that it is not a finished product which you should use at your own risk. Proper OPSEC would also help you greatly along the way.

Put it in simple sense, just figure out how much protection you need and apply mechanisms accordingly with understanding on it’s internals. For now, it’s quite implausible to run around with a high assurance solution all the time as it can be rather inconvenient (and as a result of govt agencies trying to subvert secure comms since beginning of time).

@Nick P, Markus Ottela
Does the TFC have it’s own TA prevention methods ? That is the part I am not very sure about since TFC simply sends out strings of encrypted communication out but there is no mention of TA prevention. Would TA prevention be useful for TFC ?

Thoth • November 8, 2014 9:03 PM

@Nick P
If they have seL4 for CHERI, it would be really useful for such security chips.

I would agree that the firmware and chips of the RPi wouldn’t be considered trustworthy.

Thoth • November 9, 2014 7:37 AM

@Figureitout
It is hard to be not harsh when you see another pitfall someone is going to walk into. For those who are in this industry (ITSec or Mil-Industry guys), you know the familiar stale and rotting stench of this very industry controlled by Governments. Blame the EAL 3/4 encryptors and HSMs that have been dressed as high assurance devices when they are not.

It is better to realize that Mooltipass is walking into a huge pitfall and to wake everyone up and show them how to do stuff properly (and also practically) than to see people walking into more pitfalls.

@Nick P, Markus Otella
I was wondering how I am going to send a last resort message (when nasty things happen) to a partner. One idea is to reserve certain bit strings of the OTP keystream and to agree on a last resort message. By encrypting the last bit streams with the last resort message and probably doing a HMAC on the message with the last bit stream or the 2nd last bit stream, you can more securely send out a last resort message.

If my last resort message is “IAMOWNED” which is an 8 byte message in ascii, I would need 64bits of the same length key stream and let’s say I take the 64bits of key bits from the last 64 bits of the OTP keystream, I will have 2^64 bit of key mats and if birthday attacks actually have a use here, I have 2^32 bits roughly of key mats and that is simply too easy to guess for NSA/GCHQ/BND…etc.. How about if my message is something very short which the keystream and the word length is of the same length and thereby under the influence of a short word length, I have an equally short keystream and that will make a bruteforce easy.

My proposal is to copy how block ciphers work. Use a fix length of a strong length and do your XOR on it. Pad the blocks and you are good to go. We can’t assume the user is going to do something sensible to hide their TFC messages. I will recommend a block of 128 bits per down/up stream of message. Considering the keystream size would be 128 bits because the message is 128 bits. That would effectively be as good as trying to crack a 128 bit key. You may push it a little down to 96 bits but no more than that and if you want more security, a 256 bits block message per down/up stream (which is a modern 256 bit key size). Store the encrypted message blocks in a buffer and for every 3 millisecond, flush one block down stream. This will give the crypto-engine some time to do it’s stuff to control traffic flow. If you have a message at 257 bits (you will need to use 3 blocks of 128 bits) with a wasted 127 bit padded stream but the flushing down of 384 bits of messages of 3 blocks at regular 3 millisecond intervals would confuse the adversary to think there is 384 bits of messages when it actually has 257 bits. They gotta guess 2^384 keystream bits for the key bits.

@Mooltipass et. al.
My pointing out of Mooltipass problems have to be harsh otherwise the point does not get itself across. Facts are facts. Very sorry. It would be nice if the owner of the Mooltipass project knows about all these vulnerabilities and join in the discussion to make it more resilient. We have good people here who know what they are doing.

@Tor Traffic Analysis et. al.
It’s probably only a matter of time someone breaks Tor really badly and the Tor team becomes untrustworthy if that happens. New protocol comes and old protocol goes. Nature’s work I guess ?

Thoth • November 10, 2014 1:49 AM

@Daniel
If USA/FiveEyes HSA/MSA can take it down, Russia, China and other nations can. It is only a matter of time. This good grace will not last long as the other powerful nations or rogue nations would sooner or later develop such abilities and turn into HSAs.

Tor has turned unreliable or was it unreliable against HSA from the start ? Here’s a thought I have, in a highly secured high assurance environment, a misconfiguration would usually be isolated and the high assurance security trusted environment would not be violated. If you could run a misconfigured or malicious setup and start leaking, I wouldn’t call it high assurance high security. I would call it low assurance low security. Tor uses crypto and it’s huge network of nodes to attempt to hide correlations of network traffic but it fails to take into consideration the environmental factors that includes the physical machine, the user program setup, the traffic flow analysis weakness and many more.

A more extreme but also a high assured method to end all these trouble is to build from scratch a secure trusted communications setup that handles all these problems. A misconfiguration should not allow severe leaking of internal states of system or should fail gracefully. The use of high assurance isolated kernels (seL4 and the such) with a minimal TCB would be preferrable. Owning a high assurance customized machine would be difficult and costly but the best that can be done is something along the lines of a properly configured open hardware system like the Raspberry Pi (although it is not made for security assurance). Mitigation methods to prevent catastrophic exploitation to de-anonymize programs or to compromise security within the system should also be a pririty as we have seen in the recent events. In the moment of an emergency, a self-destruct to ensure survivability and integrity of other users would also be a bonus. Traffic analysis resistance and tamper detection (at least) or tamper resistance (even better) would help a lot.

Thoth • November 12, 2014 5:37 AM

For those who want to post secure setup ideas or have theories to publish on cryptography or kleptography, I have decided to setup a space (blog) for the publication. You may drop me notice here on Schneier’s blog or contact me to get your materials published there but I do not promise web traffic. I am planning to possibly expand it in to full fletch site and probably add in some form of secure publication mechanism if opportunities arise.

Link: http://simplecrypt.blogspot.sg

Thoth • November 12, 2014 10:12 AM

@Clive Robinson
Indeed a very good idea to some sort of scatter ashes into the wind and see who can grab the ashes kind of scenario.

I guess a more TOR like secure communications method would require a rewrite of everything that is out there. The TFC chat with it’s custom hardware and bold use of OTP that sends out fix length multicast messages in some form of timed burst (or random short burst) would be the next step ?

Thoth • November 12, 2014 9:33 PM

@Uncle Bob
These traders have very little understanding of OPSEC so it’s not surprising they got caught. It is rather unsurprising and at the same time unnerving to know the fact the extend of spying even on traders in private conversation or should I say, the extend of surveillance to every aspect of one’s life.

Security should be made simple and convenient with a certain assurance level according to it’s role.

For those who want basic security, they can take the first step by using RetroShare and to know how to store their keys securely by storing the crypto keys in a portable SD card which will be kept away unless needing it’s use and nothing else kept in the SD card. Another way (if they are willing to learn and willing to spare some money) is to get a CC EAL 5+ and above smartcard or smartcard HSM module. There are no promises that the smartcards or smartcard HSM have Government traps in them but if properly deployed, they would be secure to a certain degree. One common method is to get a few smartcards from a few unique vendors and each of them generating a keypair and a secure message encrypted in a cascading manner by all the smartcards in one’s possession and if any of these smartcards are honest, there is at least one layer of protection.

Current most PKCS11 enabled software may not automatically allow cascading crypto-device protection as I explained above unless it is done by a custom script or manual effort.

Thoth • November 13, 2014 6:58 AM

@sandra
Would it be possible for us be able to request for code reviews to ensure the assurance levels of these security software suites. Many security software have shown to be vulnerable to software and hardware based attacks and it would be nice if we can be assured.