Download fulltext - DiVA Portal

8.6
Strong authentication
107
SEEDING THE RANDOM NUMBER GENERATOR
First time the user opens the application he will be required to generate randomness for
the random number generator. This will be indicated by a screen showing an explanation and a gauge that increases when he press the buttons. After the application has
gathered enough randomness, the secure random number generator provided by Bouncy
Castle will be initiated with the random seed. Then the seed will be stored in the MIDlet
record store.
When the user opens the application again, he will not be required to follow this procedure unless he chooses to do so by opening the randomness generator in the settings
menu. Instead, the random seed is read from the RecordStore, and the current time
in milliseconds is mixed in to keep the seed from being the same each time. The new
seed, with the time mixed in, is then stored in the record store and used to initiate the
random number generator.
KEY PAIR AND CERTIFICATE GENERATION
After seeding the random number generator, the user will move on to generating a key
pair for use in the strong authentication mechanism. He can abort the operation if he
wishes, but otherwise the keys will be generated and the user will be required to check
that the information in the certificate is correct. If there are any empty fields, he will
be asked to fill them in.
When the user is satisfied with the content of the certificate he presses ”OK” and the
application attempts to contact the certificate signing service. The signing service will
be presented with the certificate and a request to sign it. Upon examining that the information contained in the certificate is in accordance with the requirements, the server
will ask for the OTP. If the certificate is of class ”High”, the clerk working at the public
office will enter his special OTP, but otherwise the user will enter his OTP in the screen
showed by the application.
If the certificate signing service accepts the OTP, it appends its signature to the certificate and sends it back to the application. The application will then store the certificate
in its record store. The user will be prompted for a password to use as an encryption key
for the private key. He is asked to enter the password twice and the application makes
sure that the two passwords are identical. Then the application encrypts the private
key and stores it in the record store. If there is a certificate or private key of the same
certificate class in the record store already, it will be deleted and replaced with the new
certificate or private key.
During the attempt to get the certificate signed by the certificate signing service, there
are a couple of new errors that may occur. All of them result in the certificate signing
service refusing to sign the certificate and a subsequent error message displayed on the
user’s screen. Such errors will occur if the OTP is not valid. Another cause is if the
certificate signing service cannot verify the user’s existence in the Norwegian Central
Register of Persons and that the national identity number corresponds with the name
as required by SA-11.