WiFi networks need to be configured every now and then, e.g. to set up a guest WiFi, change the password, change the channel to a less crowded space, or activate MAC-filtering to kick my neighbours out. With LEDE I can do all of that with a straight ssh. No way I will maintain Java alive on my Mac just for this.
The tipping point for me was a bug in the Ubiquiti firmware, I systematically had to boot the AP twice to get it working. LEDE is perfectly stable.
The Unifi controller is largely overkill when you just have one AP to manage. Booting up 200 megs of Java software on a desktop to just tweak a few bits quickly became old. Re-flashed my Unifi AC Lite with LEDE and configured it through Luci. I can happily forget about Unifi controller and maintaining a live Java stack on a desktop.
They are quite different beasts. HSMs offer tamper protection through various physical means like wrapping all components in resin, or implementing self-destruction mechanisms. Smart cards protect their secrets against all kinds of side channel attacks trying to read keys off a thermal signature for example.
TPMs in most cases are based on smart cards but can also be implemented in a TEE (Trusted Execution Environment). Security does not always mandate tamperproof hardware.
Theoretically yes, though you would have to explicitly switch the original HSM into backup mode, an operation that requires one or more admins to be present and strongly authenticated, most often with smart cards.
Nope, TrustZone is not tamperproof, cannot resist determined attackers who have access to the hardware. HSMs and smart cards are designed precisely to cover this use case.
Account was closed a while back. Now I can still log in, but only thing I can do is watch my bill increase and my attached credit card stay attached until they charge it. Online fun!
For what it's worth: I created an account to try it out in January, played a bit with a cheap instance, and deleted the instance. Got billed in February (about 1€) while there was strictly no activity going on. Got to wait until end of March for the account to close, and with everything turned off I can see another bill coming in for 0.50€. Cannot remove my credit card details.
Don't care much about the undue handful of euros, but I would not trust them for billing.
Since the Apple chip is derived from an ARM design it would make sense to have the secure enclave implemented with TrustZone rather than being provided as a separate piece of hardware. Most probably a TEE (Trusted Execution Environment). Lots of TEEs are based on L4.
Definitely that, and the fact they cannot be copied. OTP fobs offer the same convenience but are based on shared secrets that can be stolen from the server (happened to RSA). With PKI your private key is only on your smart card and nowhere else.
Certificates are public, they don't need protection. The private keys do. That said you always want to store a certificate close to its private key for practical reasons.
Smart cards are useful to transform your keys into a real object that is carried around and presented upon request. They offer the interesting property that they cannot be copied or used by illegitimate users, at least not without spending horrendous amounts of time and money. When your smart card is lost or stolen you can always revoke the credentials it contains on the server side and get new ones. Much harder to know when your browser key store was stolen from your computer.
There are browser-side APIs to generate key pairs, but there is no real standard as the KEYGEN tag is not widely supported, so on the server side you need to implement virtually one method per browser type you are addressing. And then you want to store your private keys somewhere safe, which is implemented differently by OS/browser. Some browsers use the system keystore for storage, others like Firefox have their own implementation (NSS). We are not lacking implementations here, merely browser standards.
To answer your question: I do not think startssl supports local key generation for all OS/browser combinations, they probably (painfully) hardcoded the most common ones.
On mobile clients they can be quite convenient though. No need to remember any password and good protection against shoulder-surfing.
Relevant: https://www.youtube.com/watch?v=ybNWOhI-Q-4
I also have trouble believing is that 3G/4G networks would not be affected. All of these protocols are based on symmetric cryptography, i.e. a shared secret between Operators and their SIM cards. Once you get the shared secret you have the keys to the kingdom.
Their protection is that many MNOs are using proprietary authentication algorithms, making it harder to scale global surveillance. But that applies equally to 2G/3G/4G.
In many cases you have specific procedures in place for security-conscious MNOs, but some of these procedures are such a pain that you inevitably end up finding workarounds to get the business going, e.g. email or USB tokens between various people who are not supposed to have those keys.
Of course security officers and other officials are not aware of this. Dig through any sales mailbox and you will find CSV files (usually called output files) containing Ki encrypted with simple DES. I let you ask around to learn which DES key is most often used.
Disclaimer: this is not specific to Gemalto.
I can confirm this. In many cases these keys are exchanged over email with simple DES encryption and a key known to everybody in the business (pretty obvious key BTW). It really boils down to the security procedures in place between the SIM manufacturer and Mobile Network Operators.
SIM cards don't know anything about the network they are running on, this all happens inside your terminal. They hold an IMSI (=contract #), a set of private keys, and some utility applets. SIM cards don't even know their own phone number.
As for running a known-secure firmware: in the end a SIM card only authenticate you against a Mobile Operator with a pre-shared key. If you believe your SIM is running a non-secure firmware, how can you trust your Mobile Network Operator not to do fancy stuff on their network behind your back?
SIM cards are just your average smart cards dedicated to do mobile network stuff. You can buy your own blank smart cards from Gemalto and Oberthur if you so wish.
Javacard is not Java. No OO, no classes, no GC, no floats, no strings, the only data type you can use is int16. Have fun.
I have been working on OTA platforms for years with Mobile Network Operators worldwide, and I have yet to meet one that is only using DES for OTA keys. All the ones I know are using 3DES. Not sure where Nohl is getting his estimations from. Half a billion SIMs? Show me the data.
For this attack to work remotely you need to send a binary SMS and be able to read the SIM answer, which probably requires some privileged access to an operator's SS7 network. Far from obvious. Since Network Operators are in complete control of SMS traffic, blocking anything that has not been issued by their own OTA platform is just a matter of configuring a filter on an SMS-C -- if not already done.
You do not own the SIM card, it remains full property of your network operator. As such, they have a right to keep you off-limits.
FYI: the main Javacard applet on a SIM card is the GSM applet, the one you use to authenticate against your network. Other applets are useful for network operators: IMEI tracking sends them your phone ID to help them configure it correctly -- it is also used to track stolen phones. Another useful one updates your preferred foreign network list when you change countries, connecting you automatically to a cheaper network when available.
Uploading your own software will not do you much good. As mentioned above, CPU and memory are very limited on SIM cards, and Javacard is basically a glorified assembler you do not want to touch. SIM cards are mostly there to perform some simple crypto operations for network authentication and that's it.
Agreed if you configure your HTTPS server to accept certificates from any issuer. But if you restrict it to a smaller list of CAs, users are only prompted to choose among their certificates matching those CAs.
It definitely works with recent Chrome versions. I use this daily to check my professional webmail on an Android 4.2.2. Once you have provisioned a PKCS#12 into your keystore, open Chrome onto an HTTPS web site that requires certificates from your issuer and the certificate choice dialog pops up.
I am totally baffled that copy/pasting an image can be considered legally binding in 2013. Digital signatures with x.509 certificates have existed for ages now and these are rightfully legally binding anywhere in Europe.
Please have a look at European laws about digital signature!
Free.fr was once a real game changer, but that was 10 years ago. Over the past few months they have been caught red-handed filtering Google services (starting with YouTube) in order to pressure Google into footing the bill for their peering. Did not work so far, now they go for the ads.
I have no say in the Free.fr/Google quarrel, but as an end-user I could not accept being taken hostage. The first time I could not access Gmail, Google.com, or Google play for several days, I took it as a breach of their contract and switched ISPs.
Sure there are workarounds. But why should I have to jump through hoops when my account at Amazon is already entrusted with a European credit card and merrily charging euros for all other goods?
One recurrent issue with Amazon services is that they charge in US$ and currently do not accept euros. European banks charge an arm and a leg for micropayment conversions: last time I got a bill from AWS for 0.02$ it ended up costing me 20 euros or so. Pretty much kills the deal.
One solution could be to pre-pay 100$ on an account and let them debit as needed.
Look for secure microSD cards: they are smartcards with a microSD form factor and a couple of GB of normal flash storage. You can store private keys in there and negotiate certificates with a PKI server, resulting in a full-fledged S/MIME-compatible mail in your pocket. Take the card off: without your keys the BlackBerry cannot decrypt anything. Steal the phone unlocked: you have three attempts to guess the smartcard PIN. As far as I know, BlackBerry devices are the only mobile platform supporting such local hardware keystores natively.
It has taken years for Apple to implement on iOS half of the crypto available in BlackBerry devices, and they are still knee-deep in badly implemented security. Android and Windows Mobile are not even trying.