Soft hands with heavy weapons - stories of LTTE child soldiers

A new set of books on LTTE child soldiers are to be released soon, hopefully late September.

These unveil just a bit of brutality and cruelty the LTTE released on generations over the past.

Kids were given weapons and forced from play-ground to the battle field.

They lost their parents, brothers and sisters - what else, LTTE killed their childhood in the name of so called 'Liberty' of Tamil people.

All the child soldiers in these stories unveil the truth. They cried and cursed LTTE.

Parents listening to their stories will neither join nor support Tigers.

LTTE is not an organization to bring Liberty to Sri Lankan Tamils, but a group of heartless people who always brought tears in to innocent Tamils.

They exploited the innocence in Tamil kids to inseminate the seeds of anger.

They mislead the courage in Tamil youth to fire bullets against Buddhist priests.

The author of these books spent nights in North & Eastern province, areas - under SLA control, meeting LTTE child soldiers.

Books will be translated in to both English and Tamil.

Creating a new JKS with an existing private key and a signed certificate

You have your own private key and a CA signed certificate - and now you want to import both the key and the certificate to a new JKS.

This is how we do it and you need to have OpenSSL installed.

For Windows you can download Win32 OpenSSL v0.9.8g from here.Once installed make sure you add C:\OpenSSL\bin [i.e [INSTALLED_LOCATION]\bin] to the PATH env variable.

If your key and certificate are in PEM format, then you need to convert them into DER format. [privateKey.pem & signedCert.pem]

:\> openssl pkcs8 -topk8 -nocrypt -in privateKey.pem -inform PEM -out privateKey.der -outform DER

:\>openssl x509 -in signedCert.pem -inform PEM -out signedCert.der -outform DER

Copy the resulted signedCert.der and privateKey.der to c:\keys.

Java keytool does not support a direct way of importing an existing private key to a new key store. So, we'll be doing it programmatically.

You can download the code from here and copy it to c:\keys.

c:\keys\>javac BuildJKS.java

c:\keys\>java BuildJKS privateKey.der signedCert.der mykeyalias MyJKS.jks keypassword storepassword

The above will create a JKS with the name MyJKS.jks and the key store password will be storepassword while the private key password is keypassword. Also the alias of the imported key is mykeyalias.

To verify that the JKS being created properly just issue the following command to list certificates stored in the key store.

c:\keys\>keytool -list -keystore MyJKS.jks -storepass storepassword

Detecting Information Card Support

Following javascript will help you to detect Information Card support of a given browser and display Information Card based logins accordingly.

function isSupported()
{

  var ieversion = -1;

  if (navigator.appName == 'Microsoft Internet Explorer' ) {

    if (new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})").exec(navigator.userAgent) != null) {

      ieversion = parseFloat(regExp.$1);

      if (ieversion >= 7) {

        var embed = document.createElement("object");
        embed.setAttribute("type","application/x-informationCard");
        return ("" + embed.issuerPolicy != "undefined" && embed.isInstalled);

      }

      if (ieversion < 0 && navigator.mimeTypes && navigator.mimeTypes.length) {

        var handler = navigator.mimeTypes['application/x-informationCard'];

        if (handler && handler.enabledPlugin)
        return true;

        if (document.addEventListener) {

          var event = document.createEvent("Events");
          event.initEvent("IdentitySelectorAvailable",true,true);
          top.dispatchEvent(event);

          if (top.IdentitySelectorAvailable == true) return true;

        }

      }

    return false; 

    }     

  }

}

Information card support for IE 7+ is added using a browser add-on. To test the above script with IE 7+.

Personal Information Cards Under the Hood

Personal Information Cards provide a way where you can use them to register yourself with a web site and further use it to authenticate yourself.

This eliminates the burden of typing all your personal information each and every time you register with a new web site.

Once you have a personal information cards with the required claim values, the same card can be used at different websites for the purpose of registration and authentication.

This raises a question...

How come a given web site identifies you as a unique idenity based on your information card ?

Each and every information card has a non-editable claim value - known as Private Personal Identifier [PPID]. This is generated by the CardSpace it self.

For each personal information card you create, CardSpace generates a master key and a Card ID. Master key is 32 bytes of random data and Card ID is a GUID. This makes each card created unique from the rest of the cards.

PPID is not just unique for the information card it self.

It is a unique value for the Information Card + Relying Party combination.

PPID is generated with the CardID and with some properties from the RP certificate.

In case RP does not have a certificate, then it's the domain name from the site url is used along with the Card ID.

Apart from the PPID, CardSpace also creates a public/private key pair for the personal information card.

CardSapce uses the master key of the card along with some properties from the RP certificae to generate this public/private key pair.

Relying Party can retrieve the public key and the PPID from the Information card submitted to it and the user information can be stored against the PPID.

All the information sent with the card will be signed by the private key corresponding to that card.

So, once an RP gets a Card for authentication - it can verify the uniqueness of the user with the PPID and check the integrity with the public key.

The PPID generated by the CardSpace is a Base64 encoded SHA1 hash. This looks something like;

2QLepiNor3AfYCJ2tN9m3IlNXKNA/iwpVV+FCU1ZhxQ=

That is never readable and to avoid that there is a way you can generate a much readable site-specific id from it.

Mooshup: The youngest member of the OpenID family

WSO2 Mashup team recently upgraded their community site, Mooshup, with the Mashup Server 1.5.1.

With this, Mooshup enbles OpenID login - in addition to the Information Card based login, which it had already supported.

Randall says, the OpenID initiative, a 'waste of energy'.

Randall Stross in his recent article to The New York Times, highlights some of the very valid issues against the use of passwords.

"I once felt ashamed about failing to follow best practices for password selection — but no more. Computer security experts say that choosing hard-to-guess passwords ultimately brings little security protection. Passwords won’t keep us safe from identity theft, no matter how clever we are in choosing them."

Best practices on selecting better passwords always only provide guidelines for how to select a password which is 'hard to guess' - NOT unbreakable. With this point, I totally agree with Randall - Yes, true - passwords do not seem to be the 'right' solution for digital identity.

He further adds.

"As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code."

Yes, true - information cards provide a cryptographic solution to the authentication problem in a phishing resistant manner.

Even in this case - passwords are not totally taken out of the picture.

A given information card can be backed by a username/password, a self-issued information card or an X.509 token.

Also, in all three cases - if your machine, where you have installed all your Information cards, is protected by username/password - still we have not totally eliminated the risk of using passwords. Anybody who steals your machine username/password can easily use any of your information cards to authenticate in to any of the relying party web sites who accept your information cards.

Here comes the most interesting part of Randall's article.

"We won’t make much progress on information cards in the near future, however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative. OpenID promotes “Single Sign-On”: with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials."

Oops... I am sorry... I totally disagree.

First I disagree with him on the point about Information cards.

CardSpace has made a good progress in the past and it will definitely in the future. It's not just Microsoft that has taken the CardSpace initiative forward - but it has also attracted many open source vendors as well. For example, WSO2 with it's Identity Solution has support for CardSpace - both as an Identity Provider as well as providing relying party components.

Second - I totally disagree with him on his comments on OpenID.

"...however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative."

When such a comment is made - there needs to be enough facts to elaborate more on it. But, unfortunately there is nothing in it to justify.

Both OpenID and CardSpace are two technologies which support user-centric identity.

When you say - 'OpenID vs CardSpace' - it's simply an invalid statement. It should be 'OpenID and CardSpace'. Both the technologies work together smoothly. Please read this blog post by Kim Cameron.

"...OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site."

This is totally misleading.

OpenID specifications never promote a single way of authenticating users to the OpenID Provider.

It can be username/password ,X.509 certificates or even Information cards.

I can take out many examples from the the web which support many of these authentication mechanisms for user authentication.

Randall, further adds.

"...Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised."

Once again - it seems Randall has misunderstood OpenID as a way of password-based login - sorry, sir - it is not.