Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

The documentation on this page is currently in an unreviewed state.

The keyservice is a key exchange service, which is to say, you provide some credentials and in return gets a key. (if the credentials are correct).

The reason for its existence is to avoid having to store a user chosen password on a device, which can then be brute forced (since it's an offline verification of the password). The point is to make the password verification online, that is to say that the device cannot know whenever a password is correct or not before communicating with the keyservice.

The keyservice is then instructed to lock a key after certain tries, which then limits the attacker vector, and makes brute forcing impossible (you can still with low certainly guess a password, but it's quite unlikely).

Usage

  1. The user (citizen) logs into the eHealth Infrastructure using the federated NemLogin service.
  2. Once logged in, the user is issued the RT, AT and ID token (seeĀ Authentication and authorization).
  3. The user then provides the app with a secret (PIN code or Biometric code) and invokes the "createKey" on the Key Service with the secret.

Keyservice management

There are 2 types of management,

  1. The cleanup of keys, which can be configured (say after 2 months of inactive / not using a key), where it is simply deleted it, or that the maximum lifetime of a key is for example 1 year, that means no matter how much it is being used, it will be deleted after a year, forcing the user to do a new login.

  2. The management from the users perspective, respectively to be able to view his/her's devices, and to be able to delete them.


  • No labels