Venturing in the World of Web Applications

Bonjour Robert B3302!

2008-07-28T06:54:00.000-07:00

Aha, there we go! Finally our Tomcat Server was able to say Bonjour Robert! Well, not quite, since Robert's first name is actually Robert B3302 but hey who would like their name not spelled entirely?

So how did we get there?

Well any HTTP Servlet should implement the following methods:

doGet(HttpServletRequest request, HttpServletResponse response)
doPost (HttpServletRequest request, HttpServletResponse response)

Whenever a GET or POST request is sent to the server from the HTTP Client, either the doGet or doPost method is triggered. We can then use the request and response parameters to treat incoming information and return the results.

This looks a bit like this:

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
Enumeration headers = request.getHeaderNames();
String message = new String("");
message += "Bonjour " +request.getHeader("First_Name")+"!\n";
Writer w = response.getWriter();
w.write(message);
}

This extracts the value of the "First_Name" header from the GET request and sends the response "Bonjour !"

Now how are we going to make sure the first name of Robert is present in this "First_Name" header. Well since Robert identified himself with his eID card, the informations of his certificate are set as environment variables on the apache server. There is a CGI script called "printenv" in any apache server that gives the current environment variables and their value. If we connect in SSL on our proxy and trigger this script ( https://localhost/cgi-bin/printenv ), here is what we get:

DOCUMENT_ROOT="/usr/local/apache2/htdocs"
GATEWAY_INTERFACE="CGI/1.1"
HTTPS="on"
HTTP_ACCEPT="text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
HTTP_ACCEPT_CHARSET="ISO-8859-1,utf-8;q=0.7,*;q=0.7"
HTTP_ACCEPT_ENCODING="gzip,deflate"
HTTP_ACCEPT_LANGUAGE="en-us,en;q=0.5"
HTTP_CERTIFICATE_INFO="/C=BE/CN=Robert SPECIMEN (Authentication)/SN=SPECIMEN/GN=Robert B3302/serialNumber=71717100052"
HTTP_CERTIFICATE_NAME="Robert SPECIMEN (Authentication)"
HTTP_CONNECTION="keep-alive"
HTTP_COUNTRY_CODE="BE"
HTTP_HOST="192.168.212.128"
HTTP_KEEP_ALIVE="300"
HTTP_NATIONAL_REGISTER="71717100052"
HTTP_USER_AGENT="Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1"
HTTP_USER_NAME="(null)"
HTTP_USER_SURNAME="(null)"
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin"
QUERY_STRING=""
REMOTE_ADDR="192.168.212.1"
REMOTE_PORT="51616"
REQUEST_METHOD="GET"
REQUEST_URI="/cgi-bin/printenv"
SCRIPT_FILENAME="/usr/local/apache2/cgi-bin/printenv"
SCRIPT_NAME="/cgi-bin/printenv"
SERVER_ADDR="192.168.212.128"
SERVER_ADMIN="you@example.com"
SERVER_NAME="192.168.212.128"
SERVER_PORT="443"
SERVER_PROTOCOL="HTTP/1.1"
SERVER_SIGNATURE="
Apache/2.0.54 (Unix) mod_ssl/2.0.54+OCSP (1.0.8) OpenSSL/0.9.8g Server at 192.168.212.128 Port 443
\n"
SERVER_SOFTWARE="Apache/2.0.54 (Unix) mod_ssl/2.0.54+OCSP (1.0.8) OpenSSL/0.9.8g"
SSL_CIPHER="DHE-RSA-AES256-SHA"
SSL_CIPHER_ALGKEYSIZE="256"
SSL_CIPHER_EXPORT="false"
SSL_CIPHER_USEKEYSIZE="256"
SSL_CLIENT_A_KEY="rsaEncryption" SSL_CLIENT_A_SIG="sha1WithRSAEncryption" SSL_CLIENT_I_DN="/C=BE/CN=SPECIMEN Citizen CA/serialNumber=200501" SSL_CLIENT_I_DN_C="BE" SSL_CLIENT_I_DN_CN="SPECIMEN Citizen CA" SSL_CLIENT_M_SERIAL="0100000000011AC9A7F30E" SSL_CLIENT_M_VERSION="3" SSL_CLIENT_S_DN="/C=BE/CN=Robert SPECIMEN (Authentication)/SN=SPECIMEN/GN=Robert B3302/serialNumber=71717100052" SSL_CLIENT_S_DN_C="BE" SSL_CLIENT_S_DN_CN="Robert SPECIMEN (Authentication)" SSL_CLIENT_S_DN_G="Robert B3302" SSL_CLIENT_S_DN_S="SPECIMEN" SSL_CLIENT_S_DN_serialNumber="71717100052" SSL_CLIENT_VERIFY="SUCCESS" SSL_CLIENT_V_END="Jun 27 10:53:24 2010 GMT" SSL_CLIENT_V_START="Jun 27 10:53:24 2008 GMT"
SSL_PROTOCOL="TLSv1"
SSL_SERVER_A_KEY="rsaEncryption"
SSL_SERVER_A_SIG="sha1WithRSAEncryption"
SSL_SERVER_I_DN="/C=BE/ST=Belgium/L=Wavre/O=Imexis/OU=eid.imexis/CN=jeango.imexis.net/emailAddress=jeangobert.decoster@imexis.net"
SSL_SERVER_I_DN_C="BE"
SSL_SERVER_I_DN_CN="jeango.imexis.net"
SSL_SERVER_I_DN_Email="jeangobert.decoster@imexis.net"
SSL_SERVER_I_DN_L="Wavre"
SSL_SERVER_I_DN_O="Imexis"
SSL_SERVER_I_DN_OU="eid.imexis"
SSL_SERVER_I_DN_ST="Belgium"
SSL_SERVER_M_SERIAL="F34F01731A03C4B7"
SSL_SERVER_M_VERSION="1"
SSL_SERVER_S_DN="/C=BE/ST=Belgium/L=Wavre/O=Imexis/OU=eid.imexis/CN=jeango.imexis.net/emailAddress=jeangobert.decoster@imexis.net"
SSL_SERVER_S_DN_C="BE"
SSL_SERVER_S_DN_CN="jeango.imexis.net"
SSL_SERVER_S_DN_Email="jeangobert.decoster@imexis.net"
SSL_SERVER_S_DN_L="Wavre"
SSL_SERVER_S_DN_O="Imexis"
SSL_SERVER_S_DN_OU="eid.imexis"
SSL_SERVER_S_DN_ST="Belgium"
SSL_SERVER_V_END="Jan 15 09:27:41 2014 GMT"
SSL_SERVER_V_START="Jul 25 09:27:41 2008 GMT"
SSL_SESSION_ID="AB9DEAC038C8A1F4625898D8141620FCEB596E1369E83ECAE76A704B8C23B0BA"
SSL_VERSION_INTERFACE="mod_ssl/2.0.54+OCSP (1.0.8)"
SSL_VERSION_LIBRARY="OpenSSL/0.9.8g"

As you can see there is a lot of information about the current SSL session. The part highlighted in red is all information regarding the client that connected. We can see that there is a variable containing robert's first name: SSL_CLIENT_S_DN_G

We can then use the RequestHeader primitive in the Apache configuration to add that information to a header we will call "First_Name":

RequestHeader set First_Name "%{SSL_CLIENT_S_DN_G}e"

Now with our reverse proxy correctly configured, our tomcat server running with our implementation of doGet, let's see what happens.

Yay!

What has kept me busy lately

2008-07-25T05:14:00.000-07:00

It's been a while, hasn't it?

Well I realize I haven't updated this blog a lot recently, but that's because I was working hard to get the first results towards "Bonjour Robert!"

First thing first, the architecture has changed a bit compared to my first idea on how to say "Bonjour Robert!"

From applet to Reverse Proxy architecture

We figured out that the management of the smart card on the client's side was already done by firefox, through the registration of Belgian eID PKCS#11 module in the browser. So the idea was to set up a reverse proxy that would ensure secure access to imexis' website http://www.imexis.net

So this would consist of 3 steps

1) install the reverse proxy
2) configure the reverse proxy to map the access to www.imexis.net
3) configure firefox and connect to the reverse proxy (which should result in an access to www.imexis.net)

Well, step 1 was not really a piece of cake if you ask me. First I wanted to install the proxy on my Mac, but I soon faced problems to compile the apache server and the openssl server (openssl is used to create self-signed certificates and private keys for the server). After several attempts I decided to use a Virtual Machine with a Ubuntu Linux distribution on it. This way it would be easier to have information on forums (running apache servers on Linux is a very common thing), and I would be sure not to have any compatibility issues. Moreover, the documentations I had available to me covered the case of a Linux installation.

So I installed a program called VMWare that makes it possible to run my Virtual Machine, and installed Ubuntu (yeehaa, welcome to the Linux world).

Next step was to follow the procedure found in the Belgian eID Authentication Reverse Proxy User's Guide. The document may seem straightforward but it is important to understand every single step of it thoroughly. This is of course what took me a while to realize. It had already been 3 days since I first tried to install it on my Mac, and yet I hadn't progressed an inch with that installation. It took me one more day to figure out how to get all the necessary components for Ubuntu, and to finish the compilation and installation of the apache and openssl server.

Venturing in the World of Linux

I wanted to talk a bit about Ubuntu before I go on with this. Since I spent a lot of time discovering all sorts of things with Linux and Ubuntu.

First the most important thing to remember with Ubuntu is the apt-get command. If you need to install an application on your Operating System, like for example a text editor, or a GNU C Compiler you don't need to look it up on the internet (like you would for windows XP), there is probably a package made by its creator, that you can download and install simply by doing

apt-get install gcc

You don't need to do anything else, which is magical (and probably one of the reasons why people like Ubuntu so much). There is also an application that provides a more graphical interface to apt-get which is called aptitude.

I had used Linux before, but with a graphical interface, and at that time I didn't really use it in depth. I still have a lot of things to discover of course, but it is really a pleasure to start with all this. It can also be frustrating not to know how to do things but I hereby salute my friends who helped me out when I was lost, and also the internet community which is very active and contains zounds of useful informations.

Configuring the proxy

Let's get back to our reverse proxy :-) So I had compiled and installed apache, now it was time to configure the beast, and that's also a tough task. The documentation mentioned above contained all I needed of course, but in order to understand what I was doing, I used the apache documentation a lot.

First thing, I had to configure the SSL part of apache (that enables secure connection). This is all managed by an apache module named mod_ssl

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html

I then had to create the self-singned certificates by using openssl. This is made in 3 steps:

1) generate a private key for the server:

This key will serve to encode outgoing information from the proxy, and can only be decoded by the public key (as I explained a few posts before)

openssl genrsa -out server.key 1024

Openssl will create an 1024 bits RSA key. You are then prompted by openssl to specify which hashing algorithm will be used, as well as other options and specifications about the owner of the key.

2) generate a certificate signing request

A certificate needs to be signed in order to be accepted. With our private key we can generate an signature request, that can then be sent to a Certificate Authority who will officially sign the certificate. You can also sign it yourself, but in that case, whoever receives this certificate on his browser will be warned that it is not signed by a trusted source, and the user will be required to either accept or reject that certificate.

openssl req -out req.csr -new -key server.key -sha1 days 2000

3) Self-sign the certificate

Since this certificate will be used for testing, I don't really need to have it signed by a CA (I know I can trust myself =-)) so I can sign it myself this way

openssl x509 -in req.csr -out server_cert.pem -req -signkey server.key -days 2000

Once that is done, I can then configure my apache server to use the server_cert.perm as a certificate, and use server.key as private key.

Next step is then to configure the reverse proxy. Without going into too many details, I can ask my reverse proxy to map incoming adresses to another adress I choose. So if my apache server is called via https://www.jeango.com I can map the folder /imexis to http://www.imexis.net

This way if someone goes to https://www.jeango.com/imexis he will actually see the page on www.imexis.net but this will be totally invisible to him.

Amongst other things I had to configure, I had to include the OCSP access which is a protocol used to validate the status (valid, revoked, suspended, blocked) of the incoming certificates.

Pains and Tribulations

Needless to say this didn't happen with a snap of a finger, as a matter of fact I first had a lot of problems with the compilation of apache, and it took me a lot of time to understand every configuration of the proxy. Then when I finally had this finished, the server wouldn't start in SSL mode, I found out that I had configured something twice in the files, which generated a conflict, but still it didn't work so I uninstalled everything, recompiled, re-installed, re-configured and today it finally works.

Identifying with eID

Now that our server is set up, it is still needed to configure firefox correctly, and for this, it is required to have installed the middleware for eID smartcards, and follow a procedure described in this document:

http://www.google.be/search?q=firefox+eid&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

The document says that when trying to access a server, the browser will automatically ask to insert the card in the reader if there is none, but here it doesn't work. Instead I get a page saying that the SSL Handshake failed, I'll have to look into this.

Anyways, after doing all this, I inserted Robert's ID card, typed in my browser the SSL adress of my apache server and magic happened, the browser asked me which certificate to use, then prompted for my PIN, and sure enough, I saw before my eyes the welcome page of our magnificent imexis website :D

So what's next?

Well now I'll start playing with an apache tomcat servlet and see how we can interact with the card to finally say "Bonjour Robert!".

That's all for today ;) if you found the courage to read all this, send me a mail saying "bonjour robert!" (you should know my email, if you don't, well thanks for reading anyways :-))

We're getting there

2008-07-11T07:45:00.000-07:00

Today I walked through a first bit of the tutorial mentioned yesterday. It uses the Sun PKCS Provider rather than the IAIK, but thanks to this I didn't have any problems doing things with my eID card yet :-)

So what did I discover today:

1) The application needs the PIN of the eID card in order to retrieve the keystore from it.

I had first understood that the middleware is in charge of asking the PIN to the user whenever access is required on the card, but it appears that it is only when you try to sign a document using the eID certificate. However, when trying to load the keystore, the card still requires a PIN, but the middleware does not take this in charge. My application will have to prompt the user for his PIN by itself.

2) Java is not C

Sounds quite logical :-) But I had been used to program in C++ the last 5 years and some things you take for granted are just not the same between 2 different languages.

- You can't pass parameters by adress in Java: I had been used with C to pass parameters using their adress in memory by declaring a function like this

void myFunction(&myParameter)

however Java doesn't allow this and I've had a couple of null pointer exceptions due to this :-)

- if- statements in java only take boolean expressions: yup doing a "if(0)" doesn't work in java, you have to do "if(false)" which forces me to change the way I do things usually :-)

3) If you extract the private key from a card, you (of course) don't receive the key, however you receive an interface to it, so you can use the private key of the card in order to encrypt things with your own application.

4) This is what Robert's Keystore looks like:

Alias: Signature
Certificate: [
[
Version: V3
Subject: SERIALNUMBER=71717100052, GIVENNAME=Robert B3302, SURNAME=SPECIMEN, CN=Robert SPECIMEN (Signature), C=BE
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: Sun RSA public key, 1024 bits
modulus: 111899004514677203975482680672457570043331903119364034993322459228336832793594157819803568047708327522971826323979035590293818486088844003602382173875129626305902858937460678602889653574636726434057504712532262721186297169714208939386549047411126558783930559439408311683949057257680413784877522799171531680927
public exponent: 65537
Validity: [From: Fri Jun 27 12:53:29 CEST 2008,
To: Sun Jun 27 12:53:29 CEST 2010]
Issuer: SERIALNUMBER=200501, CN=SPECIMEN Citizen CA, C=BE
SerialNumber: [ 01000000 00011ac9 a806ad]

Certificate Extensions: 7
[1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
S/MIME
]

[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: D6 A5 FE 65 26 BF 28 6C 16 15 D7 FA 7E 3D DA 9F ...e&.(l.....=..
0010: A9 EE 7D 1D ....
]

]

[3]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http://crl.specimen-eid.belgium.be/eidc200501.crl]
]]

[4]: ObjectId: 1.3.6.1.5.5.7.1.3 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 0E 30 0C 30 0A 06 08 03 90 0E 07 01 05 02 01 ..0.0...........

[5]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Non_repudiation
]

[6]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [0.3.2062.7.1.1.402.1]
[PolicyQualifierInfo: [
qualifierID: 1.3.6.1.5.5.7.2.1
qualifier: 0000: 16 29 68 74 74 70 3A 2F 2F 72 65 70 6F 73 69 74 .)http://reposit
0010: 6F 72 79 2E 73 70 65 63 69 6D 65 6E 2D 65 69 64 ory.specimen-eid
0020: 2E 62 65 6C 67 69 75 6D 2E 62 65 .belgium.be

]] ]
]

[7]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[accessMethod: 1.3.6.1.5.5.7.48.2
accessLocation: URIName: http://certs.specimen-eid.belgium.be/belgiumrs.crt, accessMethod: 1.3.6.1.5.5.7.48.1
accessLocation: URIName: http://ocsp.specimen-eid.belgium.be]
]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 6E FF 99 0A 71 BB 84 A6 06 D1 04 A3 04 1F D3 18 n...q...........
0010: 3F 01 50 9B 86 73 0C 5C 2E D7 5E E3 11 9C 5E 36 ?.P..s.\..^...^6
0020: 6E B5 DD 0C 87 82 6A 0E 3A C7 1D F2 0D 22 15 48 n.....j.:....".H
0030: 7E 15 5D 14 99 62 B1 B6 FC 69 2B DA C7 5C EE 8B ..]..b...i+..\..
0040: 12 83 E6 2D 76 51 BB 0C DA DD 9C 2E 31 48 E9 50 ...-vQ......1H.P
0050: 43 D4 6F CA 37 34 55 79 17 B7 67 6D 22 67 DB 47 C.o.74Uy..gm"g.G
0060: 82 D5 B8 E8 0F B1 1D 7C 68 35 43 A9 B5 01 33 5D ........h5C...3]
0070: 08 A1 25 78 B8 2E EA 4E 00 82 F0 B3 E1 AC 1B 00 ..%x...N........
0080: 19 64 AB 5F 6E 72 28 62 5B C8 EE 03 62 71 F8 34 .d._nr(b[...bq.4
0090: 29 26 D0 9F 42 85 09 98 8A 25 D7 27 00 8B FA 33 )&..B....%.'...3
00A0: D9 34 54 3F 91 0C DD DF 04 AC AE FE 8F A5 89 4E .4T?...........N
00B0: 36 29 97 F0 42 B3 AF 0F 57 7E C2 DF A9 38 34 80 6)..B...W....84.
00C0: CA 4C 02 0A F5 77 A6 9D 03 F3 EA 00 46 B1 3D 84 .L...w......F.=.
00D0: 1F 08 08 EE A5 5F 13 CF C3 F9 26 CF 0D 53 0A 97 ....._....&..S..
00E0: B2 03 B7 58 9B BF D9 28 FB 52 B7 3C 3A A1 01 12 ...X...(.R.<:... 00F0: A8 9F 16 1B 2E 08 40 B7 E1 75 D3 A6 99 FA C4 55 ......@..u.....U ] Private key: SunPKCS11-SmartCard RSA private key, 1024 bits (id 8, token object, sensitive, unextractable) Alias: CA Certificate: [ [ Version: V3 Subject: SERIALNUMBER=200501, CN=SPECIMEN Citizen CA, C=BE Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 2048 bits modulus: 24309273447568538957156508466386268898415107335583551368823688961531705079858783447021374034717678833842586327744977882297899684641705067012968690088631174500351522865180182888170119129058775225366268794191985793208393299880134419639983160415259625386713053446067097986752764309316649169158468766774476967742379020065001838762054459624239706015643265240392612772679901414395230002154233213833013517108509388982200906819138940918447369151838771328362186158931798953602761192508322372556024064991148488514456745237140603698272392833864221074287313455535322067490438534891963751597500625651621237287559503514429481168119 public exponent: 65537 Validity: [From: Thu Dec 23 12:00:00 CET 2004, To: Mon Jan 27 00:00:00 CET 2014] Issuer: CN=SPECIMEN Belgium Root CA, C=BE SerialNumber: [ 11111111 11111111 11111111 11111115] Certificate Extensions: 7 [1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false NetscapeCertType [ SSL CA S/MIME CA Object Signing CA] [2]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: D6 A5 FE 65 26 BF 28 6C 16 15 D7 FA 7E 3D DA 9F ...e&.(l.....=.. 0010: A9 EE 7D 1D .... ] ] [3]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 67 5C 8F 5D 98 A4 3C CC C5 F6 1F 71 20 D3 86 0F g\.]..<....q ... 0010: 3D 1B 2F 35 =./5 ] ] [4]: ObjectId: 2.5.29.31 Criticality=false CRLDistributionPoints [ [DistributionPoint: [URIName: http://crl.specimen-eid.belgium.be/belgium.crl] ]] [5]: ObjectId: 2.5.29.32 Criticality=false CertificatePolicies [ [CertificatePolicyId: [0.3.2062.7.1.1.400.1] [PolicyQualifierInfo: [ qualifierID: 1.3.6.1.5.5.7.2.1 qualifier: 0000: 16 29 68 74 74 70 3A 2F 2F 72 65 70 6F 73 69 74 .)http://reposit 0010: 6F 72 79 2E 73 70 65 63 69 6D 65 6E 2D 65 69 64 ory.specimen-eid 0020: 2E 62 65 6C 67 69 75 6D 2E 62 65 .belgium.be ]] ] ] [6]: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ Key_CertSign Crl_Sign ] [7]: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:0 ] ] Algorithm: [SHA1withRSA] Signature: 0000: 2B 8A 4E 07 C9 B8 88 81 65 CD 65 5D 01 EF 08 8C +.N.....e.e].... 0010: E4 88 BE 49 0A D6 32 08 A1 AB 0C 2C 40 8C F4 18 ...I..2....,@... 0020: FC A4 61 13 55 DE 02 C3 C2 F1 67 C3 6D 96 0C D6 ..a.U.....g.m... 0030: 13 F8 0B 27 C0 47 D1 ED 5D BF 79 C9 A4 0F 0F 3D ...'.G..].y....= 0040: 57 07 CA D4 19 5F CD AF FC 71 0F 9B 46 F3 F8 A4 W...._...q..F... 0050: 12 2F 4C 4D 72 8C 0D D8 63 80 A1 A5 02 59 9C E0 ./LMr...c....Y.. 0060: 1F 55 F6 85 B7 84 85 67 08 B2 EB 83 2E 92 37 5F .U.....g......7_ 0070: 72 B9 30 AC DB D6 58 55 1F F0 DA D6 70 9E 8C C9 r.0...XU....p... 0080: D0 B6 20 05 EB A1 48 76 96 B9 AA 46 7B B1 4E A9 .. ...Hv...F..N. 0090: 83 C4 E5 01 B7 94 AC D0 E6 75 35 06 09 60 7E 9F .........u5..`.. 00A0: 29 31 E7 07 6B B6 FB 6E DC B8 45 61 47 D6 52 BC )1..k..n..EaG.R. 00B0: F0 79 79 61 3D 12 AF 4D E0 62 41 8B 61 C7 01 E1 .yya=..M.bA.a... 00C0: 23 FB 81 15 F5 CE FC 76 9D 8B 52 D7 5D 66 D2 0F #......v..R.]f.. 00D0: C1 15 A8 D0 38 40 C5 3D 38 FF 46 57 0C E0 15 F2 ....8@.=8.FW.... 00E0: 36 75 F4 0D D0 EA C3 A5 D1 09 0E 7D 0E 40 89 CD 6u...........@.. 00F0: 1B 5E D5 3F 1F D2 7A 3B B9 C3 CA E8 8E 44 8B 42 .^.?..z;.....D.B ] Private key: null Alias: Root Certificate: [ [ Version: V3 Subject: CN=SPECIMEN Belgium Root CA, C=BE Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 2048 bits modulus: 26691376432534724492914239230536419796245516068532173901583967047600268926599080494681481520702134118891565316669898570691114551706817351962178500667181029693650065893361463787785300509028117452231414940342359485172277604079140049287137596689084656358926439744495271507065982288770837970026835661043448496256726253647767817292995578739674090998624027230583215392405441418148657818976769620253079041070042952983293214469145330275436682586834300598436530165781418685318418982623744621632911090583722316269620253757229959960866058867588475478638980377832743068439889482014217721312571288986733070918469283356832727190777 public exponent: 65537 Validity: [From: Wed Aug 13 11:00:00 CEST 2003, To: Mon Jan 27 00:00:00 CET 2014] Issuer: CN=SPECIMEN Belgium Root CA, C=BE SerialNumber: [ 11111111 11111111 11111111 11111112] Certificate Extensions: 6 [1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false NetscapeCertType [ SSL CA S/MIME CA Object Signing CA] [2]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 67 5C 8F 5D 98 A4 3C CC C5 F6 1F 71 20 D3 86 0F g\.]..<....q ... 0010: 3D 1B 2F 35 =./5 ] ] [3]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 67 5C 8F 5D 98 A4 3C CC C5 F6 1F 71 20 D3 86 0F g\.]..<....q ... 0010: 3D 1B 2F 35 =./5 ] ] [4]: ObjectId: 2.5.29.32 Criticality=false CertificatePolicies [ [CertificatePolicyId: [0.3.2062.9.6.1.31.1.1] [PolicyQualifierInfo: [ qualifierID: 1.3.6.1.5.5.7.2.1 qualifier: 0000: 16 2A 68 74 74 70 3A 2F 2F 72 65 70 6F 73 69 74 .*http://reposit 0010: 6F 72 79 2E 73 70 65 63 69 6D 65 6E 2D 65 69 64 ory.specimen-eid 0020: 2E 62 65 6C 67 69 75 6D 2E 62 65 2F .belgium.be/ ]] ] ] [5]: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ Key_CertSign Crl_Sign ] [6]: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] ] Algorithm: [SHA1withRSA] Signature: 0000: 2F CC F7 B0 2F 29 2B 00 5A 2C BC 31 5A 4A E5 20 /.../)+.Z,.1ZJ. 0010: 6B C8 06 09 4D 2F C9 1D 7E 6A 55 F4 D4 50 81 C5 k...M/...jU..P.. 0020: 75 49 DA DE 12 CD 14 A9 89 DB CA 16 8E E0 01 D3 uI.............. 0030: 85 2E E1 1F E6 61 76 61 BB 8E B1 E3 6C 19 A6 2C .....ava....l.., 0040: 8F 82 99 0E 98 D1 8B 60 CE BB 3F 92 1A AA DD CB .......`..?..... 0050: 5B CA 2A C7 77 47 B5 38 12 C1 67 1C 50 64 E4 98 [.*.wG.8..g.Pd.. 0060: B1 9D 70 E7 BC 3D A7 61 CE A3 76 E9 F7 23 8A 6D ..p..=.a..v..#.m 0070: C1 2D E1 0E 75 20 71 45 B4 56 1E 4B E0 97 8C 3B .-..u qE.V.K...; 0080: BB 77 FC DD EC A3 26 FD D6 9A 58 14 9C 6A 30 A3 .w....&...X..j0. 0090: 26 DD 67 22 6A CD F7 DB 7F 2D 48 B5 93 3B 5C 4E &.g"j....-H..;\N 00A0: EC 6C 86 BE 8F 47 7A DE CD 69 BA 8A A1 22 B0 3E .l...Gz..i...".>
00B0: 83 16 5F 9B B5 33 95 7C 5A 31 55 D8 9A CB CA EC .._..3..Z1U.....
00C0: 57 7C 18 DC 30 47 20 EA 35 15 7D B8 3C 60 B3 59 W...0G .5...<`.Y 00D0: 56 50 B3 A8 03 C8 2D 28 0D 2D 12 1D 35 62 E0 AB VP....-(.-..5b.. 00E0: ED E5 53 54 43 4B 68 BB 98 00 B6 78 E7 C7 93 06 ..STCKh....x.... 00F0: E4 46 C6 5C 65 19 C4 00 D3 79 4D C4 45 76 0F DF .F.\e....yM.Ev.. ] Private key: null Alias: Authentication Certificate: [ [ Version: V3 Subject: SERIALNUMBER=71717100052, GIVENNAME=Robert B3302, SURNAME=SPECIMEN, CN=Robert SPECIMEN (Authentication), C=BE Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 1024 bits modulus: 99118761443669422291498760732724032715373214217302511965045964772871859003736852323149962836757489278007171937318381868594464271689448425826496925091035462057600115094523702878251665568942712725243978766284465174977057852526309353417744114866030522499405177739161556746031358035987771634436298681323393403787 public exponent: 65537 Validity: [From: Fri Jun 27 12:53:24 CEST 2008, To: Sun Jun 27 12:53:24 CEST 2010] Issuer: SERIALNUMBER=200501, CN=SPECIMEN Citizen CA, C=BE SerialNumber: [ 01000000 00011ac9 a7f30e] Certificate Extensions: 6 [1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false NetscapeCertType [ SSL client S/MIME ] [2]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: D6 A5 FE 65 26 BF 28 6C 16 15 D7 FA 7E 3D DA 9F ...e&.(l.....=.. 0010: A9 EE 7D 1D .... ] ] [3]: ObjectId: 2.5.29.31 Criticality=false CRLDistributionPoints [ [DistributionPoint: [URIName: http://crl.specimen-eid.belgium.be/eidc200501.crl] ]] [4]: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature ] [5]: ObjectId: 2.5.29.32 Criticality=false CertificatePolicies [ [CertificatePolicyId: [0.3.2062.7.1.1.401.1] [PolicyQualifierInfo: [ qualifierID: 1.3.6.1.5.5.7.2.1 qualifier: 0000: 16 29 68 74 74 70 3A 2F 2F 72 65 70 6F 73 69 74 .)http://reposit 0010: 6F 72 79 2E 73 70 65 63 69 6D 65 6E 2D 65 69 64 ory.specimen-eid 0020: 2E 62 65 6C 67 69 75 6D 2E 62 65 .belgium.be ]] ] ] [6]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [accessMethod: 1.3.6.1.5.5.7.48.2 accessLocation: URIName: http://certs.specimen-eid.belgium.be/belgiumrs.crt, accessMethod: 1.3.6.1.5.5.7.48.1 accessLocation: URIName: http://ocsp.specimen-eid.belgium.be] ] ] Algorithm: [SHA1withRSA] Signature: 0000: 48 89 61 2B EB DC 68 67 47 DA 33 9E 82 11 C4 40 H.a+..hgG.3....@ 0010: 6C 47 DD A7 6D 97 0D 95 C6 7C 81 FB 79 46 95 E1 lG..m.......yF.. 0020: 73 9C 5F 30 9B C3 96 42 E5 AE A6 FC 2F 54 9C 39 s._0...B..../T.9 0030: 1C B3 F7 5E 77 50 7B EB C9 17 92 9B 09 3D A0 89 ...^wP.......=.. 0040: 76 B4 8B F4 AE 20 EC F0 80 01 F4 63 DD 29 A0 D8 v.... .....c.).. 0050: 77 DE AD 95 05 E9 F9 D5 7B 49 60 A1 24 F6 DF 28 w........I`.$..( 0060: ED 0C 83 71 14 BD BE EE 0A FB AE C3 B0 3D 15 FD ...q.........=.. 0070: EF 58 14 54 40 80 07 2F 77 85 72 14 F1 90 B4 06 .X.T@../w.r..... 0080: F4 4B 35 A5 76 BF 6A 0C 3D AE 7C D4 95 8B 41 DD .K5.v.j.=.....A. 0090: 57 D2 F3 1C FC B0 53 C6 9F D8 63 71 AB 00 9D 57 W.....S...cq...W 00A0: 4C 2D 58 43 56 44 9A 2B 34 3D 07 13 3C 7C F5 F3 L-XCVD.+4=..<... 00B0: 17 96 31 E2 FE AC F4 65 25 78 05 C6 D3 62 30 0E ..1....e%x...b0. 00C0: 28 2E 89 54 A6 49 B7 1C AC A8 59 01 45 29 29 7B (..T.I....Y.E)). 00D0: C4 66 07 13 91 A0 F7 DF 28 F9 A9 20 FC FF FC 07 .f......(.. .... 00E0: 7F 9E D9 0D A0 D4 36 14 CE C3 94 3E C2 30 EC C3 ......6....>.0..
00F0: 95 33 7A EE F7 28 C5 33 15 58 86 D6 48 77 3D E3 .3z..(.3.X..Hw=.

]
Private key: SunPKCS11-SmartCard RSA private key, 1024 bits (id 1, token object, sensitive, unextractable)
Retrieving the Provider Name
Unregistering the Provider SunPKCS11-SmartCard

4) Man, this is fun!

Yeah, I just have to say that today I had a lot of fun putting some code together, and seeing how it works. That's one thing I love about developments: making things work :-)

Tutorial: How to build a java Applet to sign documents with a smart card

2008-07-10T08:37:00.001-07:00

Wow! That was a long title :)

Anyways, here is a very interesting tutorial that I am currently following to inspire myself for "Bonjour Robert!"

http://www.developer.com/security/article.php/11580_3587361_1

Decomposing "Bonjour Robert!"

2008-07-10T07:47:00.000-07:00

"Bonjour Robert!" may seem a simple thing to do, but it is not really trivial in terms of programming.

Let's make an overview of the different steps it will take before we can say "Bonjour Robert!":

1) Someone says hello to me and presents his ID papers (eg. he inserts his card in the reader)
2) I ask this person "Are these your papers?" (the program asks to prove that the person is the owner of the card)
3) The person "proves" that these are indeed his papers (he gives the PIN code)
4) I check if his papers are valid (are the certificates from the card valid, revoked, suspended?)
5) I read his name from the papers (the program accesses the information found in the ID card)
6) I say "Bonjour Robert!"

Here we work in an environment composed of 3 distinct parts:

- The program (in Java)
- The card + reader
- The middleware (software that enables communication between the program and the card)

The card is provided by Robert, the middleware is installed on the computer and is standard, so the part we can work on is the Java program.

The first and probably hardest part, will be to authenticate the card (steps 2-3-4) so I'll start there. But how does authentication work then? Well inside the card's chip there is a so-called "Private Key" and also a "Public Key".

Private Key / Public Key

When the card sends information, it is encrypted with the card's Private Key. This key is known only from the card and no-one can read it or access it.

In order to read that information, it can only be decrypted with the Public Key, which can be known by anyone.

On the opposite side, the program can send information to the card and encrypt that information using the public key. Only the private key can be used to decrypt that message.

What this means is that if the program receives an information from the card, if that information can be decrypted with the card's public key, then the program is certain that the information really comes from the card and not a third party that tries to hack the conversation. This way, a hacker can't fool the program into believing that he is the owner of the card, nor can that hacker read any information that the program sends to the card (he can't decode it because he doesn't have the private key).

So this is how the program and the card establish a communication, however this still doesn't prove that the ID card is not a fake. This is ensured by the use of Certificates (but I'll talk about this tomorow).

"Bonjour Robert!"

2008-07-10T01:09:00.000-07:00

In the programming world, when you learn a new language, or you try to use a new technology, the very first program you make is usually a very simple one that says "Hello world!"

My current project is to make my own eID client-server program in which the client will authenticate itself to the server, and then the program will fetch the first name from the card and use it to say hello to the authenticated user.

In this case the first name of our test card subject is Robert, as you can see on our specimen testcard:

Now this is pure coïncidence, but there is actually a boardgame named "Bonjour Robert!" So doing a "Hello Robert!" program is much less fun than doing a "Bonjour Robert!" :-) Click on the image to know more about the "Bonjour Robert!" game.

Did You Know: eID Card Stop?

2008-07-09T05:50:00.000-07:00

If you loose your eID card, you might want to consider calling eID Card Stop

French speaking: +32(0)2 518 21 16
Dutch speaking: +32(0)2 518 21 17

More interesting websites

2008-07-09T03:27:00.000-07:00

I discovered this very interesting Wiki:

http://wiki.yobi.be/wiki/Main_Page

there is a section about security that is of particular interest for me, and a very extensive subject on eID

Also, through yobi wiki, I discovered a blog about security that has countless information on security, and more specifically the belgian eID. It presents a critical view of all the security issues and is very frequently updated with news on the subject.

http://belsec.skynetblogs.be/

Also here is a forum about Eid

https://securehomes.esat.kuleuven.be/~decockd/wiki/bin/view.cgi/Eid/EidForum

There is also (but it is in french) the website of the "Agence Wallone des Télécommunications"

about eID: http://www.awt.be/web/gov/index.aspx?page=gov,fr,fic,020,001
about Electronic Signature: http://www.awt.be/web/sec/index.aspx?page=sec,fr,fic,150,001

Proxies and DMZ

2008-07-09T02:27:00.000-07:00

Since I will probably be talking quite a bit about proxies in the future, I thought I might as well give a small introduction :-)

Proxy

A Proxy is a system (computer, or software) that acts as a middle man between two systems (eg. two computers). One of these systems, called the client, wishes to gain access to a specific ressource (software, data, ...) that is present on another system (called the server). The client contacts a proxy, asking access to the ressource, then the proxy will ask the server for that ressource and will then forward the informations from that ressource to the client.

In the the eyes of a client who uses the proxy, every ressource is an individual entity. In the eyes of the server, there is no distinction made between the clients using one same proxy.

Reverse Proxy

In some cases (web services for instance) one same service can consist of several ressources that are spead amongst several servers. In order to present a single interface to the client, the provider of that service needs a system that will dispatch in-bound requests to the correct server. This is what a Reverse Proxy does: present several ressources as one single entity to the client. Also, since the reverse proxy is controlled by the provider of the service, additional security features can be implemented there, amongst other things (load distribution, data compression etc).

When using eID as a means to authenticate a user, the reverse proxy will manage the verification of the certificate.

DeMilitarized Zone (DMZ)

A service provider may not feel comfortable receiving queries from an external network directly on their internal network. Indeed, some information on their internal network may be sensitive data that the owner does not want to share with the world. Though still he wishes to allow the external network to have acces to some public parts of his network while still being able to access it from his secured internal network. This part of a network that is freely accessible to both the external network and the internal network is called a Demilitarized Zone (DMZ). Usually the DMZ is located between two firewalls, one which separates the internal network, and one which separates the external network.

Typically, in the case of web services, the reverse proxy will be located in the DMZ, while the application servers (containing the different ressources accessed by the service) will be located in the internal network.

The IAIK JCE Provider

2008-07-08T08:17:00.000-07:00

I talked earlier about the Provider abstract class. There can be different implementations of that abstract class. The toolkit from certipost came with an implementation of the PKCS#11 Provider made by IAIK (Institute for Applied Information Processing and Communication). I'll be working with that provider to manage eID authentication.

The CD received from certipost doesn't contain much information on how to use this provider (anyways, I couldn't locate that information on the CD). The IAIK website does have a javad oc of the provider's API however the javadoc alone is not really sufficient to understand how to use the provider.

There was a link to some user guide in the javadoc, but the link was dead. Fortunately, through some clever google shenanigans I eventually found the document.

This contains a lot of very useful information and I'm starting to see how this will all fit in an actual program. Looking at the sample codes provided by certipost, I now start to have a better understanding of some strange programming choices. I can feel your curiosity :-) Here is a sample code that looked really strange:

Security.insertProviderAt
(new iaik.pkcs.pkcs11.provider.IAIKPkcs11(), 2);
Security.addProvider(new iaik.security.provider.IAIK());

Basically what this does is register which provider implementation is going to be used. The strange thing about this is that the first provider is inserted at the second position, and then the second one is added at the next position (ie. the third position). It turns out that the reason for this implementation is that there is a bug in java 1.4 that prevents inserting a provider at the first position.

Funny :-)

Now though I really have a lot to do yet to be ready for tomorow's presentation to the bosses :-( good new is I finally start to feel like I'm understanding things rather than hovering above a massive uncharted rainforest of knowledge.

At last some results

2008-07-07T09:10:00.001-07:00

I still didn't manage to run that stupid client-server application, however I tried a simpler program that just gives back the information on the objects that are present on the eID card. It appears that the PKCS Module's library must be addressed directly in the code:

Module pkcs11Module = Module.getInstance(args[0]);

here the file name is passed as an argument of the run command.

The instantiation of the pkcs module in the case of the client-server application is managed by a dependency, so I'd have to dig in a little deeper if I wanted to get the thing to work, but right now it is not my primary concern.

The information about the card that was displayed by the program was only information that is available through PKCS. Namely, information about the certificates, and information about the keys (private and public). However the actual data (first name, last name etc.) must be adressed specifically through eID API's.

That will be the next point I'll work on.

Meanwhile, if you are the happy owner of a MAC computer with OS-X installed, and if you have a smartcard reader, you'll be happy to know that it is possible to configure your MAC so that you log in with your eID card (and PIN) rather than your username and password.

For more info on this, check out this blog

Understanding the usage of PKCS

2008-07-04T09:03:00.000-07:00

Yesterday afternoon I tried to compile and run a sample program that performs a basic client-server authentication with an eID certificate. However I have been unable to run it correctly.

In order to understand the reason of that error I need to understand really how all this works, but it's not really a piece of cake.

Basically my understanding is the following:

Provider -> Wrapper -> PKCS Module -> eID Card

The provider is a Java interface, the Wrapper is a JNI library that links the provider with its PKCS Implementation of the provider which in turn accesses the eID card and performs the requested operations.

However I have a problem with the wrapper, which doesn't link properly with the PKCS implementation.

Good news is: I found a lot of things to read this week-end in order to have a better understanding of how all this works.

http://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/pkcs_11_wrapper
http://forum.java.sun.com/forum.jspa?forumID=60&start=0

I also discovered a blog of a guy who works with eID cards and says a lot of useful things on the subject.

http://christophe.vandeplas.com/

Using Electronic ID Cards

2008-07-03T02:57:00.000-07:00

Belgium was the first country to introduce Electronic ID cards (eID) at a large scale a couple of years ago, and the hype progressively expands to other european countries as a means to simplify access to public services throughout EU countries. Today, around 30 million people in europe have their eID card.

eID can be used for many other things than just e-Gouvernement Services, as they provide a means for secure authentication, and electronic signature. All this is very interesting for web application developers, and we want to use this at Imexis for our own applications.

Yesterday I received a pack from certipost with an eID reader, several test cards and a software package. Today I will be trying to see how I can develop a small application that would access information on a card through the reader.

Here are some interesting reads:

http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html
http://en.wikipedia.org/wiki/Public_key_cryptography
http://en.wikipedia.org/wiki/RSA
http://en.wikipedia.org/wiki/SHA
http://ec.europa.eu/information_society/activities/egovernment/policy/key_enablers/eid/index_en.htm

The Cryptographic Token Interface Standard

RSA Security, produces the Public Key Cryptography Standards, amongst which a specific standard: PKCS#11 adresses the Cryptographic Token Interface. This standard consists in an API called CRYPTOKI (pronounce Crypto-Key). The goal is to provide an isolation between the application that uses a cryptographic device, allowing for multiple applications to access multiple devices without worrying about the specifications of that device.

Any such device (as is the eID card) is refered to as a Token.

By next week wednesday, I should have understood how exactly an application can use Cryptoki to work with a token, and what kind of operations we can do with the token, as well as the limitations.

Why start this blog?

2008-07-03T02:32:00.000-07:00

My first mission at Imexis is to familiarize myself with the technologies that I will be using. And the number of technologies involved in the development of web applications is Huge. At first I was a bit lost, trying to figure out where to start. Surfing the web, and reading forums/wikipedia entries helped a lot, so I thought: what the heck, I may as well share my discoveries and useful websites to the world. It would both help me keep tracks of things and might help some other people too :-)

Also, explaining what exactly I do for a living is not always easy, so this is also a way to help my friends and family to keep track of what I'm doing.

So there, now I'll get started with things :D

Presentations

2008-07-03T02:08:00.000-07:00

Hi there,
My name is Jean-Gobert de Coster, and I started my new job in a startup named Imexis just about a week ago.

I had previously worked as an IT-Consultant for Alten Benelux at Alcatel-Lucent where I worked on design, development, testing, integration and maintenance of an OSP-Based IN product named Convergent Rating Engine

Though my experience at Alcatel was very interesting, both professionally and humanly, it was very specific to the world of Telecoms, and I started to feel like I was no longer developing general skills through the Job.

I Always liked Java, and have been intrigued by the world of web applications, so when I heard of an opportunity to work in a startup owned by a friend of mine: Thomas de Bodt, I jumped right in, and became Imexis' first employee.