print Print
Logo: Stiftung Secure Information and Communication Technologies SIC Stiftung Secure Information and Communication Technologies SIC

Frequently Asked Questions

 

Q:

I have problems, what shall I do?

A:

We have made the experience, that many questions occuring are answered by

a) reading the documentation or

b) looking into the newsgroup or mailinglist archives or

If you still can't solve your problem, you can use our support system - and if you have bought one of our toolkits you already might be owning support-points you can make use of. Calling us by phone is only a good option if you subscribed to a support-plan that allows you to do so. Otherwise, we may reject to answer your call and direct you to one of our electronic forms of support. If you think you have found a bug, please use our bug-report-form !

Q:

Does your product support the JSSE-API?

A:

 Yes, use our JSSE wrapper as interface to the JSSE framework.

Q:

Can I use Smartcards for Client-Authentication?

A:

Yes. See our info about iSaSiLk and Smartcards.

isasilk with smartcards

iSaSiLk and IAIK JCE themselves do not have any specific provisions for use with smartcards or other secure hardware devices where the private key cannot leave the device. Nevertheless they are designed
to interoperate with such hardware devices. For instance, you may use the IAIK PCKS#11 provider for accessing smartcards, USB tokens or HSMs from your Java™ SSL/TLS application.

Q:

 We have noticed that the first call to the constructor of the SSLClient(Server)Context class takes several seconds. This has not been a major problem so far, but it seems a bit strange...

A:

 The constructor of a SSLContext creates a new default Java™ SecureRandom object. On some platforms this process may take a very long time. There are two possible solutions to this problems:
 

  1.  Immediately after starting your application, create a new thread which initiates the SecureRandom generator. When you need the first random number the seed has already been generated:
     // create a new Thread which initializes the Secure Random Number generator
     (new Thread() {
       public void run() {
         setPriority(Thread.MIN_PRIORITY);
         SecRandom.getDefault().nextInt();
       }
     }).start();
  2. Write your own Seed Generator which creates a true random seed in a faster way.

Q:

Can anyone suggest any good books on SSL V3, Cryptography etc?

A:

You could ask at Prentice HallO´Reilly, or John Wiley & Sons, e.g.: William Stallings: Cryptography and Network Security: Principles and Practice, 2/e ,
Published  in June, 1998 by Prentice Hall Engineering, Science & Math (June, 1998) Marcus Goncalves: Protecting Your Website With Firewalls, 1/eMarcus Goncalves: Protecting Your Website With Firewalls, 1/e
Published April, 1997 by Prentice Hall Professional Technical Reference Raymond R. Panko: Business Data Communications and Networking: A Modular Approach, 2/e
Coming November, 1998 from Prentice Hall Business PublishingJonathan B. Knudsen: Java Cryptography
Published by O´Reilly, 1st Edition May 1998 Scott Oaks: Java Security
Published by O´Reilly, 1st Edition May 1998 Bruce Schneier: Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Ed.
Published by John Wiley & Sons, Oct 1995 Peter Lipp, Dieter Bratko, Johannes Farmer, Wolfgang Platzer, Andreas Sterbenz: Sicherheit und Kryptographie in Java, 2000 by Addison Wesley Deutschland

Q:

I use jdk1.1.6 and OS is WindowsNT 4.0. Then, if I would use SSLSocket in iaik-ssl package, application error occured. I think it is bug of jdk1.1.6 VM (Virtual Manchine).

A:

It is a problem with the JIT of JDK1.1.6. Try to use the JVM option -nojit till the bug is fixed.
 Testing the application CipherSuiteTest we found the following problems:

  •  JDK 1.1.6 JIT: o.k.
  •  JIT EA1: o.k.
  •  JIT EA2: not o.k.

Q:

Hello, we are testing the iSaSiLk package for use in our university research project.  One of the focuses of the project is to allow for dynamic cryptographic security policies, which translated into SSL, means changing the enabled cipher suites while the connection is up and renegotiating.
 What I am wondering is how come the client-side SSLSocket cannot call renegotiate(). It seems like a lot of overhead if when the client wants to renegotiate, it has to send some out-of-band message to the server, who then sends the HelloRequest back to the client, who then sends ClientHello to actually start the negotiation.  Couldn't renegotiate(,or a new method, allow the client to just send the ClientHello, or is there something that I am
 missing here?  Will renegotiation from the client side be supported by iSaSiLk any time soon?

A:

You are right. According to the SSL 3.0 specification, a client also can start renegotiating the active cipher suite by sending a new client_hello message. Starting with iSaSiLk snapshot isasilk.2.01, it also will be possible to initiate a cipher suite renegotiation from the client side. The syntax will be the same as forcing a renegotiation from the server side: just call the renegotiate() method of the SSLSocket class for sending a client_hello message to restart the handshake procedure:

try {
s.renegotiate();
} catch (IOException ex) {
System.out.println("IOException: "+ex.getMessage());
}

 When  calling renegotiate() from the server side, first a hello_request message will be sent to the client, indicating to the client that he can start a new handshake dialogue by transmitting a client_hello message.

Q:

Regarding SSLSocket.renegotiate(), it's not clear what the calling sequence should be.

A:

Renegotiating a cipher suite works this way:

  1. A client connects to a server -
     handshaking procedure is performed -
     SSL connection is OK -
     client and server can exchange data
  2. Now the server can force a renegotiation of the cipher suit by sending a "Hello Request" handshake message to the client.
  3. The client receives the "Hello Request" handshake message and starts a
     complete new handshaking procedure by sending the first message, the "Client
     Hello" message.

 The only difference is that the handshake messages of this second handshaking procedure are already protected according to the cipher suite which was negotiated by the first handshaking procedure. So an attacker cannot even see the normal unencrypted hello and key exchange messages.
  
 The server may initiate a renegotiation by refreshing the (cipher suite) settings of the SSLContext belonging to the SSLSocket (returned by the accept() method at the beginning of the on-going session) that is used for communicating with the actual client. Then the server starts the renegotiation by means of the SSLSocket´s renegotiate() method:

SSLSocket s;
  s = (SSLSocket)serverSocket.accept();
  ...//refresh the cipher suite settings of the context belonging to s
  ...//start renegotiation
  try {
      s.renegotiate();
  } catch (SSLException ex) {
      System.out.println("SSLException: "+ex.getMessage())
  }

iSaSiLk 3.0 includes a demo SSLServer also dealing with cipher suite renegotiation.


print Print