Damn, Im really proud of myself Yesterday I completed successfully my study as computer scientist … A detailed description with some pictures will follow … 7h3 p14n 70 0wn 7h3 w0r1d c0m35 c1053r …

Here we go again, new year, new experiences, new ideas, new cognitions, new strength … Here is a piece of code that I have written for my thesis to convert a RSA key that have been created with BC into an OpenSSL readable PEM Format. This was a little bit tricky but it works.

private String getPublicKeyPEM() throws IOException
    {
        int line_length = 64;     // PEM-encoded data has 64-character lines
        int length, remaining, position=0;
        String pem_encoded_data = "";
       
        RSAPublicKeyStructure rpks = new RSAPublicKeyStructure(RSApubKey.getModulus(),
                                                               RSApubKey.getExponent());
        String key_pem_format = new                              String(Base64.encode(rpks.getDERObject().getEncoded()));
        key_pem_format = key_pem_format.trim();
        length = key_pem_format.length();
        remaining = length – position;

        while (remaining > line_length)
        {
            pem_encoded_data += key_pem_format.substring(position, position + line_length) + "\n";
            remaining -= line_length;
            position += line_length;
        }
        if (position < length)
            pem_encoded_data += key_pem_format.substring(position) + "\n";
       
        key_pem_format = "—–BEGIN RSA PUBLIC KEY—–\n"+
                        pem_encoded_data+
                         "—–END RSA PUBLIC KEY—–\n";
       
        return key_pem_format;
    }

 

Im damn proud to announce the first release of my own GINA Implementation known as BlueLogonGINA. The purpose of this Implementation is to provide a 2nd way and a more secure method to authenticate the user. Beside the normal logon by entering the username, password and by choosing the domain, the implementation BlueLogonGINA provides a new logon method by using an extern bluetooth device to logon automatically. The only requirement for the bluetooth device is that it should support J2ME MIDP2.0 and the bluetooth java api.

The BlueLogonGINA Implementation works on all Windows 2000, 2003 and XP systems. You can also use this version to replace the original Microsoft GINA Implementation. As I said, the implementation allows also to use the old logon method by entering the username, password and the by chosing the domain.

These are very important options to display the welcomescreen when starting windoze:

• "LogonType"=dword:00000000
• "DisableCAD"=dword:00000000
• "AutoAdminLogon"="0"
• "Background"="0 0 0"

It has been a while that Ive posted my last comment about new cognitions of the wincrap world. Here we go again … This time I will explain the wrong impression of using the registry keys defaultUsername, defaultPassword and AutoAdminLogon to realize an autologon. First of all why should I need an autologon ? The mechanism behind autologon can be used to automatically login the user without entering the username and password interactive. Normally available on every smartcard system. The difficult part for a GINA-programmer is to find a way to handle the SAS events to bypass the windows login dialog. My thought was to use the three registry keys defaultUsername, defaultPassword and AutoAdminLogon. The idea was pretty clear, after receiving a custom SAS event I will set the three keys. But …. this works only on special circumstances :

1. it works only after a shutdown of the computer
2. it is damn unsecure because the defaultPassword must be stored in cleartext Great work Bill!

The better way is to implement the two GINA functions WlxActivateUserShell and WlxLoggedOutSAS.

Summa summarum: If you want to code your own GINA-Implementation to automatically login a user by using an extern device just take the time to implement the two functions instead of experimenting with the three crap registry keys.

If you will use the standard methods of Bouncy Castle to verify a message signed by OpenSSL you will fail. Why ? Because it seems that both crypto engines use different signing/verifiying mechanisms. I spent two days to find out why it fails … today I have decided to write an own implementation based on the low level functions instead of finding out what goes wrong. While browsing the cvs web of OpenSSL I found my two low level functions for openssl:

 int RSA_private_encrypt(int flen, unsigned char *from,  unsigned char *to, RSA *rsa, int padding);           

 int RSA_public_decrypt(int flen, unsigned char *from,  unsigned char *to, RSA *rsa, int padding);    

The replace implementation for OpenSSL consists only of two steps. The first step is to create a SHA1 hash of the message and then to use one of the two low level functions based on the operation you want to do (signing or verifiying). The only problem is that Bouncy Castle must support my used RSA_PKCS1_PADDING. What exactly happens when signing with RSA_PKCS1_PADDING ?
Taken from RFC3447 the crypto engine creates a new byte array with the maximum size of the output block used by the engine. (e.g. RSA 1024 bit = 128 bytes maximum output block). After this the padding 0×00 and 0×01 will be added to the beginning of the byte array. The byte 0×01 marks the type of the PKCS padding. (e.g. 0×01 for type 1, PKCS1). The rest bytes will be filled with 0xff. The SHA1 hash will now be fit to the end of the byte array. To separate the padding from the data a 0×00 byte will be used as delimiter. The complete byte array looks like this:

EM = 0×00 || 0×01 || 0xFF ….. 0xFF || 0×00 || SHA1 Hash

Thats all. Here are the two replacement functions that Ive written under java:

public byte[] RSASign (RSAKeyParameters RSAprivKey, byte [] toSign) throws Exception
{
RSAEngine eng = new RSAEngine();
SHA1Digest sha = new SHA1Digest();

eng.init(true, RSAprivKey);
byte[] result = new byte[sha.getDigestSize()];
sha.update(toSign, 0, toSign.length);
sha.doFinal(result, 0);

// pkcs1 padding type 1
// http://www.faqs.org/rfcs/rfc3447.html
//
// 5. Concatenate PS, the DER encoding T, and other padding to form the encoded message EM as
//
// EM = 0×00 || 0×01 || PS || 0×00 || T.
//
byte[] pkcs1_padding = new byte[eng.getOutputBlockSize()];
pkcs1_padding[0]=(byte) 0×00;
pkcs1_padding[1]=(byte) 0×01;

for (int i=2;i<pkcs1_padding.length-result.length-1;i++)
pkcs1_padding[i]=(byte) 0xff;
pkcs1_padding[pkcs1_padding.length-result.length-1]= (byte) 0×00;
System.arraycopy(result, 0, pkcs1_padding, pkcs1_padding.length-result.length, result.length);

byte[] b = eng.processBlock(pkcs1_padding, 0, pkcs1_padding.length);

clearBlock(result);
clearBlock(pkcs1_padding);

return b;
}

 

public boolean RSAVerify (byte[] pubkey, byte [] mesg, byte [] sig) throws Exception
{
byte[] der = PEMtoDER(pubkey, "RSA PUBLIC KEY");
ByteArrayInputStream bAIS = new ByteArrayInputStream(der);
ASN1InputStream asni = new ASN1InputStream(bAIS);
ASN1Sequence asn = (ASN1Sequence)asni.readObject();
RSAPublicKeyStructure rsaps = new RSAPublicKeyStructure(asn);
RSAKeyParameters RSApubKey = new RSAKeyParameters(false, rsaps.getModulus(), rsaps.getPublicExponent());

RSAEngine eng = new RSAEngine();
SHA1Digest sha = new SHA1Digest();
eng.init(false, RSApubKey);
byte[] result = new byte[sha.getDigestSize()];
sha.update(mesg, 0, mesg.length);
sha.doFinal(result, 0);
byte[] b = eng.processBlock(sig, 0, sig.length);
int start_offset = b.length-sha.getDigestSize();

for (int i = start_offset; i<b.length; i++)
if ((b[i] ^ result[i-start_offset]) != 0) // xor for faster comparison
{
clearBlock(b);
clearBlock(result);
return false;
}

clearBlock(b);
clearBlock(result);

return true;
}

What have we learned ? Sometimes it is better to write your own stuff … where you know that it really works!

After hearing and reading that someone (greets to toni would like to see some screenshots I decided to create a little flashtro to show my first J2ME gui. I used the WTK Emulator from SUN. The only problem is that I cant show the most interesting stuff behind the project, the connection via bluetooth because the emulator cant make use of the underlaying bluetooth hardware. I had to deactive (comment) all bluetooth stuff in the code to execute the program with the emulator. Before someone starts crying about the colors, the emulator displays only 4096 colors Normally all MIDP2 compatible devices can display more than 4096 colors …  A detailed instruction on what the user should do with the J2ME tool to auth against his windows will follow …

The flashtro can be found here : flashtro.

Here is my final roadmap with all the stuff that needs to be done in a specific period.

1. Logic between client and server
2. GUI for the mobile device
1. till 14th September 2005
3. i18n for the GUI
1. till 15th September 2005
4. Choose a way to connect to WinLogon
   
1. (Intercepting/Hooking the DLL, writing own Gina DLL)
   
2. till 20th September 2005
5. Testing the first Beta-Release
1. till 22th September 2005
6. Thesis document
1. till 15th October 2005

BlueLogon supports only following mobile devices:

1. BenQ – P30 - 208×320
2. HTC – Himalaya -  240×320
3. Motorola – A1000 - 208×320
4. Motorola – V360 - 176×220
5. Nokia – 3230 - 176×208
6. Nokia – 6230i - 208×208
7. Nokia – 6260 - 176×208
8. Nokia – 6600 - 176×208
9. Nokia – 6620 - 176×208
10. Nokia – 6630 - 176×208
11. Nokia – 6670 - 176×208
12. Nokia – 6680 - 176×208
13. Nokia – 6681 - 176×208
14. Nokia – 6682 - 176×208
15. Nokia – 7610 - 176×208
16. Nokia – 7700 - 640×320
17. Nokia – 7710 - 640×200
18. Nokia – 9300 - 640×200
19. Nokia – 9500 - 640×200
20. Qtek – XDAII - 240×320
21. Siemens – S65 - 132×176
22. Siemens – SK65 - 132×176
23. Sony-Ericsson – K600 - 176×220
24. Sony-Ericsson – K750 - 176×220
25. Sony-Ericsson – P900 - 208×320
26. Sony-Ericsson – P908 - 208×320
27. Sony Ericsson – P910 - 208×320
28. Sony Ericsson – P910a - 208×320
29. Sony Ericsson – P910c - 208×320
30. Sony Ericsson – P910i - 208×320

For my thesis, I was searching for a good security protcol. My coding project named BlueLogon should implement an intelligent security protocol to ensure a secure msg exchange over an insecure communications channel. The search ends up on the very interesting SSH-2 protocol. The first Internet Draft for the SSH-2.0 protocol was submitted in February 1997 and the first software product "SSH Secure Shell"based on the superior SSH protocol was released in 1998. The major differences between SSH-1 and SSH-2 are:

• Expanded algorithm negotation between client and server
• Multiple methods for key-exchange
• Certificates for public keys
• More flexibility with authentication, including partial authentication
• Stronger integrity with checking through cryptography
• Periodic replacement of the session key ("rekeying")

SSH-2 currently defines only one key-exchange method, diffie-hellman-group1-sha1. Before we continue with the implementation of the SSH-2 like protocol in my thesis I will try to explain the used encryption algorithms for the sensitive key exchange.

Diffie-Hellman

  Merkle, Hellman, Diffie

To make it short, Diffie-Hellman key exchange is a cryptographic protocol which allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher. How does it work ? I will try to explain this with the two parties Alice and Camil

• Alice creates two prime numbers, p and g, where g must be between 1 and p-1
• Alice sends these two numbers to Camil
• Alice now chooses a secret number a and sends Camil X=g^a mod p
• Camil receives X, chooses a secret number b and sends Y=g^b mod p
• The two numbers a and b are the private keys and X and Y are a kind of public key
• Both calculates the secret key based on their received "public key"
• Camil calculates SK=X^b mod p and Alice SK=Y^a mod p, where SK is the final secret key
• Both parties calculate the same secret key because: (g^b mod p)^a = (g^a mod p)^b = (g^(a*b*) mod p)

Proof-of-concept of the communication protocol 

Every encrypted communication should guarantee four essentials features:

• Privacy of your data, via strong encryption
• Integrity of communications
• Authentication, i.e. , proof of identity of senders and receivers
• Authorization, i.e., access control to accounts

 BlueLogon protocol connection flow

The picture shows the four phases
of the BlueLogon protocol. Please
click here to view the picture in big size.

 Security threats against the BlueLogon project

• Spoofing

  The classical attack where the malicious hacker spoofes the client and try to bypass authorization phase and to lead to a successful authorization and authentication.

• System Compromising

• Replay-attacks

  Since all protocols send messages over a public channel a malicious hacker could capture
  all sended and received messages to replay them later. The result would be a successful
  authorization and authentication against the server. (Efficient protocol against guessing and replay attacks … paper, A Taxominy of Replay Attacks … paper)

• Man-in-the-middle attacks
• Traffic analysis

  A malicious hacker could guess the length of the username, password, shared key by analysing the packetsizes of the traffic between the sender and receiver. He could also
  discover informations about the protocol, possible handshakes, parties, unencrypted
  packets. (Analyses of the SSL 3.0 protocol … paper)

• Timing attacks
  
  By measuring the time of generating a RSA or a Diffie-Hellman key a malicious hacker could detect if the devices use fixed Diffie-Hellman or RSA exponent, fixed private prime numbers and can also guess the size of an exponent or prime number.  (Timing Attacks on Implementations of Diffie-Hellman RSA, …. paper)

      
[1] Securing Communication over Packet Networks