Certificate Authorities who operate on the scale absolutely do NOT keep private keys of the issuing intermediate available for harvest. That's what HSMs are for; devices which hold the private key material and perform signing operations on behalf of the CA. The CA can never retrieve the private key(s) so compromising the CA in that scenario should never result in private key disclosure.

The main issue is that Oyster does do some level of cleverness. I only ever skimmed the paper so don't recall the details. The main issue in most use cases is that the spec says the token UID should be read-only. When you can buy tokens from China which completely disregard this and let you write sector 0 it's game over immediately for huge swathes of RFID installations which rely on UID alone.

My work ID does door access, printing, loads of stuff. Spoof the UID onto a blank token, remove the chip/antenna, place inside rear cover of watch. Super convenient, but alarmingly easy.

And you know that "tap and go" stuff your credit card has, distinct to the chip & pin functionality, for low-value purchases like a Double Whopper with cheese? Don't even get me started on that...

Honestly, what the actual fuck? Have you listened to yourself?

I don't actually use public transport. I just do some NFC work for the day job and know how weak the keys are in old MiFare stuff. No wonder you posted AC with that outburst of verbal diarrhoea.

Well thanks Anonymous Coward (latin: buffoonus maximus), but that's a bit of a tenuous jump. I don't even use public transport, I'm just a guy who does a bit of NFC engineering for the day job and knows the difference between the wrong way to do it and the way I do it. The token security is weak, certainly, but it's easy to protect against with some very low-overhead crypto.

Old MiFare stuff is toast, security wise. Any old fool can order some UID-writable tokens on eBay from China, grab a copy of libnfc and mfoc, then things get interesting pretty quickly.

Well someone got out the pedantic side of the bed this morning. And no, it's an allocation of my ISP's /16. If I'd got the range from RIPE I wouldn't need PTR delegation would I?

I don't actually need the whole block any more, it was something I was doing for a PhD project a few years back. A /27 would do me these days, but they don't seem in a hurry to have them back.

Very well put. Getting a large ISP whose staff "follow the flowchart" to provide such things is not as easy as some make out. I have a number of non-catalogue products including bonded FTTC which has saved me a fortune on what I used to pay for dedicated hosting (I don't need 5 9's uptime). Instead of a call centre grunt giving a standard "We don't provide that service" response, I get a technically literate person on the end of the phone who understands what I'm asking for and says "Let me have a word, see what we can do". You pay for that kind of service, but for me it's worth it.

Not A&A actually, but along those lines. It's a little more than just PTR NS records, but that's not really relevant to the discussion.

Personally I'm not a big user of these kind of services, but it's only a handful of the "big" ISPs who are doing the blocking. I prefer a more personal service so I use a small ISP which offers special geeky extras (full class C, reverse NS delegation etc) and they perform no such blocking. But even if I didn't it's trivial to bypass such blunt instruments.

The proper way to do it is to have a 100% offline CA with its key material split over a number of smart cards so the CA can only be brought up periodically for signing purposes when a certain number of cards are present (say 3 of 5) and even then you use an HSM which performs all activities hence the private key is never accessible even if you wanted it to be. You store the cards in fireproof safes in geographically dispersed secure physical locations, cardholders travel by different modes of transport, at different times of day, stay at different hotels etc. For day-to-day certificate issuance and signing you have a subordinate CA sat in a networked HSM. That way there can only ever be a minuscule (I'd never use the word impossible) risk that the root CA can be compromised and you maintain the ability to revoke the day-to-day CA.

90% of a good PKI is process and governance, not the technology itself.

I suspect what's going on here is that the NSA has the ability to cut certs for things like *.google.com, *.facebook.com etc from a trusted commercial CA whose root is already installed in everybody's browser, hence they can man-in-the-middle the traffic without raising alarm. A few sneaky BGP advertisements and this would be surprisingly easy to do.

It's pretty shocking to read most of the comments on here and realise that very few people actually know how PKI works even at the most basic level.

I decided, having had a couple of stiff ones (drinks) this evening, to drop them a line via the website in an attempt to contribute a tiny amount of sanity and/or education.

Unfortunately I was told my email could not contain anything other then [0-9|a-z] IN THE BODY and due to my use of punctuation I was not allowed to email them. I was going to "correct" my correspondence, but the I thought "fuck it, I've got work tomorrow", and I have a glass of wine and 2/3 of a frankly very good cigar to do in.

I figured it probably would. I used to love working with Novell products and used to proudly have all my CNE/CNI certs framed in the office but left that organisation (education) before I had chance to get involved in transitioning from Netware to OES2 on SuSE. Now sat up in management towers wishing I could still be getting my hands dirty. Such is life.