Ralf sent in this report about his recent results from LinuxTag 2005…

LinuxTag 2005 was again a great success for CAcert. We, Philipp ‘Sourcerer’ and I, supported by Eric ‘Nox’, Michael ‘MiGri’ and some others assured approx. 700 people. First time, we wore (self-made V0.1) T-shirts to represent the CI of CAcert.

As a direct result of LT assurance the 3000 assurer barrier has been broken!

As super-assurers, Phillipp and I ‘only’ usually issued 120 points and encouraged the applicants to get to the full points by doing cross-assurances near by our booth so we could answer upcoming questions.

For applicants in ‘underdeveloped areas’ 😉 we issued full 150 and aske to bring some friends around to be assured so they can spin the web of trust in their region.

Usually the identity was pre-checked and the form was marked by an assurer’s aid (Eric, Migri, Steffen, …) and the assured by one of the super assurers.

Now and then, Philipp vanished for hours to the other (.com-)conference hall and built contacts to ‘Them’.

To applicant’s with an existing account the points were issued right at the booth (I had an OpenVPN tunnel to my home based network, of course secured by CAcert certificates) and all the others were asked to create their account as soon as possible.

By today, the pile of unprocessed forms is reduced to approx. 40, all of these got more than 3 reminder emails. Maybe thos mails get lost as false positives in a spam filter or thos applicants changed their mind.

So this is the end of my first entry to the blog. Please excuse typos or strange phrases. This is NOT my native language and school was ages ago 😉

Cheers,

Ralf.

P.S. Good news! For Europe, I mangaged to persuade Petra from www.kernelconcepts.de to offer high-quality CAcert T-shirts at a good price ( evend reduced if you order by CAcert-cert signed mail 😉 plus shipping. See details at http://wiki.cacert.org/wiki/t-shirts

Things are slowly coming out about what happened a month ago in New York city, and my initial questions still go unanswered, many excuses are being spun but very few answers are given freely, and this is really disappointing coming from the Mozilla guys.

Mozilla touts, like many open source projects that being open and free is a major benefit to society, yet they then have the hide to turn round and conspire with commercial interests behind close door for what we’re being told will be the benefit of the internet.

I’m not sure about anyone else but my memory isn’t that bad that I’ve forgotten how US commercial interests don’t do anything unless it will effect their bottom line, either for increased profits, or due to regulatory disputes planning to inflict fines or other restrictions that will hurt their bottom line. This is highlighted only too well in the current SPF vs Sender ID debate, Microsoft as usual came in late to the game thinking, “we’ve missed another boat, what the hell do we do now?”. What they came up with, was a small variation of SPF then turned round and requested a patent on their “innovation”!

Microsoft then did what Microsoft always does, turned round and tried to inflict their “invention” on us, but it was no olive branch, it was a thorny stem with no rose on the end, basically they have and are still trying to take control of email via a patented invention that does very little more then what SPF does, in fact they are still trying to push through their “invention” by brute force. Since the MADRID task force collapsed due to lack of consensus, Microsoft has a solution lacking mass adoption, so they are planning to mark any email being sent to their domains as junk that don’t support (or properly support) Sender ID.

So anyway back to the current story, basically Mozilla hasn’t learnt from history and they actually think they will be able to do more good then harm from closed door talks then what happened with MADRID. I doubt anyone will claim the internet could be where it is without open standards, and open discussions preceding before that, hell CAcert thrives based on open discussions, there are a lot of smart people out there with a lot of good ideas and we’d be mad to simply ignore them.

However this is exactly what the Mozilla guys have done, and in the process alienated a lot of smart specialists in the area they are trying to define, the end result will be that we all suffer, and a very good example of where this has happened in the past is with Wifi security (this is after all how CAcert begun, bad Wifi security needing something else to protect information), basically cryptography experts weren’t consulted openly and we ended up with something basically a waste of time that can be cracked in minutes, so tell me how those closed door talks helped society exactly.

Ian from FinancialCryptography has some more information on the topic on his blog as well, which is well worth the read. https://www.financialcryptography.com/mt/archives/000514.html

For anyone in the San Francisco area I’ll be stuck at the San Francisco airport from when I clear customs on the 8th of July (some time about 8pm or 9 depending on how late/early the flight is), until I need to board/clear security for the connecting flight at about 11:30pm (flight isn’t till 12:30am), so if anyone wants to be assured/have coffee/whatever I’m guessing I’ll be pretty bored by that point and welcome anyone wanting a chat, as I’ll have been on planes/in airports for about 24 hours prior… Feel free to Contact Me

In June 1-4, 2005 we had FISL 6.0 happening in Porto Alegre, RS, Brasil, which had more than 5000 participants (the count on the site is not accurate it seems).
We had a stand there, for CAcert and the Brazilian CAcert user group, in which we were doing assurances during the whole event.

We had assurance count way below our expectations, a little above 100, but we made very good contacts there, and many people got interested in the project but not confident enough to start using it yet. Many of those asked several times if there was really no cost, because commercial CAs are really unaffordable here, and the government-owned CA (ICP-Brasil) charges a good deal (R$ 400, about US$ 170) for a client certificate.

More pictures of FISL can be found here

I’ve touched on this before, but I recently stumbled upon a link again to an early example in the real world which makes the point very obvious.

The biggest benefit about biometrics and RFID tags is also the biggest problem. Biometrics and RFID are designed to not change, and make use of things such as your finger print, and in the case of RFID tags a fixed hexadecimal number. While you can never “loose” your fingerprint like you can your password, people can’t easily duplicate your fingerprints on the spot either so they start taking body parts instead.

Of course RFID tags only become a similar problem when it’s actually embedded under your skin, but already a lot of people are doing this, or contemplating doing it for more “convenience”, and while they think they only have limited range they haven’t played with highly directional antenna, people thought blue tooth problems weren’t an issue because you had to be within 10m of the person you’re targeting, that is of course until someone started playing with high gain antennas and manged to get between 100 to 1000m range to a normal mobile phone.

The US and other governments around the world are currently pushing for contact-less RFIDs in passports, as a security measure, but time and time again these “feel good” security measures don’t do much for security and simply give the community at large a warm fuzzy feeling about how their governments are protecting them with better security measures at border crossings. Quite frankly if current estimates of 10 million illegal immigrants in the US is correct what’s to stop the big bad enemy (I refuse to say the “T” word because it’s really a pot calling the kettle black) from sneaking in the same way, oh sorry forgot that they were actually buddies with guys in power and were let in the front door!

Also this little sound bite from the CAcert Support mailing list today:

Here in Nebraska we implemented a 3D bar coding system on the drivers license, and all sorts of new security features on our licenses in 2003, making them extremely hard to duplicate. Within months the machines used to manufacture them was stolen, enabling the thieves to make perfect forgeries.

At the end of the day all these new security measures do is make it easier for governments to track and control their citizens, the bad guys will still do bad things!

Continuing on with photos of PKI kit, I was sent this photo by Ralf of his Aladdin e-Token, apparently it can be submerged and survive 5m of water and 95 deg C temperatures.

I had a few more PKI cards turn up today, so far no luck with those either, even though they have been pre-loaded with a GemSAFE image. I plan to contact the local distribtor in the morning to see if we can nut something out. I did take a stanley knife to the GemSAFE card I have to fit it in the GemPC Key reader, and it works quite nicely.

Below are some photos I took earlier on tonight.
Continue reading →

Security mechanisms can be defined in the following ways “something you know”, “something you have” and “something you are”.

Passwords are something you know
PKI cards/tokens are something you have
Biometrics is something you are

The problem I have with biometrics is you can’t change the tokens, and this can be bad for a number of reasons. For example, some new cars come with a biometric reader so they can claim they are harder to steal, but as one proud new owner found out it just makes criminals hurt you more, so now he doesn’t have a car and he has one less finger, that’s right, they stole his car and cut off his finger as well!

My preference lies with something you have, that is PKI hardware, which in most cases also requires a PIN, which is something you know, which adds up to 2 factor authentication. The beauty of this system is that the PIN and the card by themselves are useless, having the card by itself is useless because if you get the PIN wrong 3 times the cards will lock themselves to prevent brute force attacks, and of course the PIN by itself is pointless.

And so begins my epic tale of getting PKI hardware to work with Linux, and the difficulty I encountered highlighting one of the many reasons PKI hasn’t taken off in a big way.

This week I met up with a nice gentlemen, who happened to be the distributor for Gemplus products in Australia/New Zealand, and was kind enough to give me a few of their products for evaluation purposes. I believe others have also managed to get evaluation kit from Aladdin as well, check the main mailing list archive for details on that.

In any case this was my first look at any kind of PKI based hardware, and as per usual for Linux driver support and integration between applications leave a lot to be desired, but the lack of coherent documentation was an even bigger headache.

Read on for more Continue reading →

One FUD issue some people keep regurgitating to keep us from being included in browsers is they worry about us issuing certificates for the likes of paypal.com, most people pushing this line tend to neglect to mention that issuing a certificate on it’s own is mostly useless, unless you can attack the host file on a users computer or the DNS name system, in which case there is bigger problems then falsely issued SSL certificates, especially since most phishing attacks (which is the assumption likely to abuse this) don’t even resort to using SSL.

Currently we require people to have code signing access before issuing IDN/punycode domain/email certificates, and it has been suggested that we have a similar requirement for anyone requesting certificates for high profile sites.

One way to determine popularity is by sites like alexa.com which give out rankings.

I guess the question is how popular must a site be if we want to enforce this, and over what time period?

Another concern is with large organisations as a lot of departments inside these organisations run their own sub-domain and the TLD is handled usually by the main IT department, and this could be cause for concern if someone registers the TLD and starts getting certificates for either the entire organisation or for sub-domains they shouldn’t be allowed to control, this is usually controlled by an organisations IT policy, but this call also lead to someone intercepting traffic by setting up a reverse proxy, and there is questions hanging over this as it will potentially effect legit users one way or another.

Many people have cited the reason for excluding us is based on our perceived ability to protect our root certificate and in fact most consider it worst then a critical browser exploit, but the more I think about this, the more I’m convinced this is just wrong, so I went to the trouble of trying to break the situation down logically, and here’s my risk analysis of the situation:

A browser exploit can effect all users of a particular browser (mozilla says 50mill so I’ll run with estimates based on that).

Browser exploits are pretty clear cut to calculate and would have the potential base of 50 million users to exploit.

A bad certificate on the other hand, the numbers aren’t so clear and you have to do some educated guessing as to what the risk would be closer to.

Without any more specific details of region break downs I’ll have to assume that the 50 million users are evenly distributed more or less on eastern and western Europe, North America, some parts of Central and Latin America and the Asia Pacific regions.

We also have to assume that most banks are either very geographically specific, or at most have a website on a per country basis and they operate different sites in different countries.

To exploit DNS effectively you either have to control a root name server or be able to exploit individual name servers of ISPs in a concurrent fashion. The banking industry and large merchants already pay large sums of money to be notified of DNS based attacks, so the risk here is going to be mitigated some what compared to normal merchant sites, and if we’re talking about normal merchants the threat is considerably lower due to lack of continuous contact that people would have, compared with their banks, and of course replication of the entire shopping cart since you need to make product selection before purchasing.

Ok, so if we evenly distribute the number of firefox copies over 6 areas and assume a penetration rate about equal we end up with about 8 to 10 million users in each location, the above numbers are spread over multiple countries so we’ll assume for the time being that at most, there are approx 3 million users in any given country.

Further to that the potential number of users likely to be effected by a DNS based attack is in the 100’s of 1000’s at most (I’m being generous, more then likely it will be MUCH less) for a banking website used nationally. To attack companies like Amazon.com or ebay.com you’d have to replicate the entire shopping cart system, of which there are easier attacks currently being deployed.

So a browser exploit is likely to effect: 50,000,000
A root certificate breach is likely to effect 100,000 or less, and that’s based on the assumption of a successful DNS breach on a mass scale, where a browser exploit may only need the user to visit a web page.

So the difference between a browser exploit having a detrimental effect or an SSL root cert exploited is somewhere in the vicinity 500x greater, although this easily could be 5000x or more depending on what figures you based your breakdown on, how proactive the bank is preventing other forms of attack so on and so forth.

Just one final note, if the domain is hijacked or even just DNS spoofed you don’t need have a root cert escape into the wild there are plenty of CAs already in the browser root stores that will issue control of domain certificates including Verisign via Thawte 123, Geotrust and Godaddy to name but a few, and this is part of the reason banks employee the services to prevent DNS based attacks, although the real reason is the fact people just don’t take enough care and verify they are connected by SSL before sending sensitive information.

So no matter how the above risk is twisted with FUD, the facts are that an SSL root key loose in the wild is highly over rated due to other factors mitigating risks.