WO2011059390A1

WO2011059390A1 - Method and arrangement relating to securing information

Info

Publication number: WO2011059390A1
Application number: PCT/SE2010/051246
Authority: WO
Inventors: Anders Hansson; Peter Davin
Original assignee: Cryptzone Ab
Priority date: 2009-11-12
Filing date: 2010-11-12
Publication date: 2011-05-19
Also published as: SE0950854A1

Abstract

The present invention relates to a memory arrangement (70, 80, 90) comprising a security driver application (71, 901) and a storage portion (72, 902). The driver application (71) is configured to, when accessed, to authenticate a user using an authentication procedure and secure and/or unsecure data on said storage arrangement. The memory arrangement is configured to execute an application being part of memory encryption policy and applicable by a central controlling system. The driver application is further configured to, based on said authentication procedure take an action being one of: provide access to said data, deny access to said data, or delete said data stored in said memory arrangement.

Description

METHOD AND ARRANGEMENT RELATING TO SECURING INFORMATION

TECHNICAL FIELD

The present invention relates to a method and arrangement for encryption and/or decryption of contents of a memory unit, especially a memory unit detachably connected to a computer device, such as a personal computer.

BACKGROUND Exchange of information, in particular privileged information between computers and users of the computers increases tremendously.

It is not unusual that the users, besides transmitting information, e.g. using e-mail applications, also store information on memory units detachable form the computers. USB (Universal Serial Bus) memories have become very popular as they allow simple connection, fast and large storing ability. Former diskettes and disk-drives are more and more rare sight in the computers.

In a computer system, peripherals and other devices may be attached to a computer system by means of a bus, such as a USB bus, FireWire (IEEE 1394), Human Interface Devices (HID), PCMCIA, etc.

A computer operative system utilizing a USB bus will include a USB software layer that will interact with applications and mediate the sending and receipt of data from a central host to the peripherals.

The USB software layer supports generic USB hardware. The USB software layer is complex and flexible, in order to support the USB communication. The USB software layer preferably supports multiple independent hardware vendors' drivers and must remain pluggable. Therefore, the USB software layer may be changed often in order to respond to challenges such as changes in hardware or other updates. Moreover, there are a large number of different USB hardware elements available, and the USB software layer is preferably able to support this multiplicity of options. Ordinary USB memories store data without any encryption, which allows easy access to the stored data, e.g. if the USB memory is lost. Currently, secured USBs are designed to work with users securing their own sticks. Some companies for example may want only their IT Administrators securing the memory sticks and then distributing to their users, so that the users do not have to do the securing process. When a USB memory is secured and accessed for first the time, the USB may be registered in a server as belonging to the user that secured it. The memory is provided with some private information belonging to the user (which is called a USB token) and this information is sent to the server to verify that the stick is actually created by the user. Thus, there is a need for a way to provide the benefits of USB or any other similar memory type connectivity, while allowing for increased security.

SUMMARY Advantages of the invention include:

• Allowing user to secure/unsecure data to a memory unit,

• Deployed through the client (the computer receiving the memory) based on policy settings,

· Encryption method controlled through policy setting,

• Ability to monitor the deployment process centrally,

• Ability to centrally configure the method of securing the memory unit,

• Ability to comply with different methods of protection that fits the user's working

methods. Ability to utilize encryption and decryption logic on any computer, without the need of additional driver installation,

• Easy usability, wizard driven deployment,

« Allows an administrator and/or a user to deploy the securing process,

• Allows logging user interactions, and keeping track of content revision history, Enforce encryption on everything placed on the memory unit • Central control over the stored information

For these and other reasons mentioned below, a memory arrangement is provided comprising a security driver application and a storage portion. The driver application is configured to, when accessed, to authenticate a user using an authentication procedure and secure and/or unsecure data on said storage arrangement. The memory arrangement is configured to execute an application being part of memory encryption policy and applicable by a central controlling system. The driver application is further configured to, based on said authentication procedure take an action being one of: provide access to said data, deny access to said data, or delete said data stored in said memory

arrangement. The memory accessing arrangement may comprise end-user processing commands used to access said data. Preferably, the memory arrangement is one of a USB (Universal Serial Bus) memory unit, digital camera, digital video recorder, Personal Digital Assistant (PDA) or a cell-phone. The memory arrangement may be configured to be connected to a host by means of one or several of a USB bus, FireWire (IEEE 1394), Human Interface Devices (HID), PCMCIA, Bluetooth or Infrared. The memory

arrangement may use an application on a host configured to guide a user and function as a link between the user and the memory arrangement. The application may be a part of memory encryption policy and applied to the user centrally. In one embodiment a user deployment configuration comprises one of: securing memory arrangement manually, enquiring to secure memory arrangement once for each device, enquiring to secure memory arrangement every time an unsecured device is used. The memory arrangement is further configured to block said data if a synchronization process in absent of a synchronization procedure within a specified time period.

The invention also relates to a method of policy based security deployment for a memory arrangement, using a first operation level, a second policy level and a third component logic level, whereby an administrator administrates said deployment policy of the second level, whereby the security deployment is transferred to said third level, in which a server communicates with a client, which is intended to receive said memory arrangement, and when said memory arrangement is received, security policies are transferred to it, whereby upon reception of a command from said server by a the memory arrangement on said component logic level, said memory is arranged to grant access to or deny access to or delete data on said memory arrangement. Preferably, when data is secured it is encrypted using suitable encrypting method. The method may further comprise a time lock feature used to lock the arrangement after a predetermined period. The method may comprise a recovery procedure operating as a secondary private password. The recovery password operates:

• assigning an id to a key-slot that holds a key used to secure the arrangement, · storing a centrally administrated user id in a user profile data base,

• using user's recovery password as a recovery seed,

• providing a key used to encrypt said arrangement as a hash,

• if the password is lost:

o authenticating the user and receiving a recovery data, o using said recovery data and the user that is the owner of the recovery data used at the time of encryption,

o authenticating the user, and

o using the recovery password for un-securing a specific content, In one embodiment the hash comprises a key identifier, user identifier and recovery seed combined. The recovery data may be the user identifier combined with the key identifier. A final recovery key is generated using: user identifier, key identifier and recovery seed.

BRIEF DESCRIPTION OF THE DRAWINGS In the following the invention is described with reference to a number of non-limiting exemplary embodiments illustrated schematically in the attached drawings, in which: Fig. 1 is block diagram showing security levels according to the invention,

Fig. 2 is block diagram showing key handling according to the invention,

Fig. 3 is block diagram showing steps of generating recovery keys according to the invention,

Fig. 4 is block diagram handling recovery keys according to the invention,

Fig. 5 is block diagram showing request and response logic according to the invention, Fig. 6 is a block diagram over the method of the invention,

Fig. 7 is a block diagram showing a USB/computer according to the invention,

Fig. 8 is a block diagram showing a memory/computer connection according to the invention, and

Fig. 9 is a block diagram showing principles of the invention, DETAILED DESCRIPTION

In the following, the invention is described with reference to a preferred embodiment of a USB (Universal Serial Bus) memory unit (memory stick). However, it should be

appreciated by a skilled person that teachings of the invention may be implemented on any type of memory units attachable to a computer, such memory units include memory sticks, digital cameras, digital video cameras, Personal Digital Assistant (PDA), cellphones, etc., which can be connected to a host such as a PC through a USB bus, FireWire (IEEE 1394), Human Interface Devices (HID), PCMCIA, Bluetooth, Infrared, etc.

Fig. 9 schematically illustrates the principles of the invention. An exemplary system may comprise a memory unit 90, according to the present invention, a user computer 95, and a server 92 communicating through a network 93.

The memory unit 90 comprises a layer of executable instructions set, i.e. driver application, 901 and stored in a portion of the memory 902, is the stored data area 9021 comprising a user profile data 9022 and the secured (encrypted) memory area 9023. The driver portion may comprise instructions for encrypting/decrypting data and

communication with the server 92.

Encryption/decryption, user identification and setup are entirely handled by the driver 901.

The profile portion 9022 may comprise protection methods for one or several users of the memory unit: The protection methods may include:

Custom,

Private,

Master,

Recovery

Secure Groups,

Enterprise Protection.

These methods are described in more detail below. The server 92, which may communicate with the memory unit through the network 93, whenever a communication is established, may include a database 920 for the user identities, user profiles, user groups, master passwords, recovery password, etc. The main password for encrypting, decrypting the memory unit sat by the user is however stored on the memory unit itself.

The following describes the parameters involved when a user 96 goes from having an unsecured memory unit to a secured memory unit. Basically, the client program (client) is configured on how to guide the user in the deployment process. Here, the "client" refers to the application program executed on the computer 95, receiving the memory unit 90. Once configured, the client program may work as a link between the user 96 and the memory unit. This will be a part of the memory encryption policy located in the profile database of the user (managed by the client), and can be applied to the user centrally. The client deployment configuration may include one or several of following (in the following USB memory device is used for memory unit):

• Secure USB memory devices manually

• Ask to secure the USB memory device once for each device

• Ask to secure USB memory devices every time an unsecured device is inserted. · Automatically secure any unsecured memory device that is inserted

According to one embodiment, the USB memory can be configured for manual deployment, and the user may have to secure the USB memory device manually. A secondary option is in the settings, where the user may select 'secure USB memory device immediately'.

The method may allow several options for securing the USB memory device. If configured for to be asked to secure an USB memory device once for each device, the client will prompt the user if he wants to secure an USB memory device as soon as he inserts the memory unit into his computer. It will only be done once for each device, since the client will keep track of the USB memory devices inserted.

If configured for to be asked each time an unsecured USB memory device is inserted, the client will prompt the user to secure the device each time he inserts it into his computer. This only occurs if the USB memory device is missing a secured area. Preferably, the process of securing an USB memory device is a wizard driven process, to be as user friendly as possible. This means that an application program assists the user to run deployment procedure step by step.

Fig. 1 illustrates a policy based deployment procedure. The procedure comprises three levels: first operation layer 10, second policy and regulations 1 1 and third component logic 12. In the operational layer 10, an administrator 101 administrates the security policy and security deployment policy of the second level. The security policy and policy deployment are transferred to level 3 comprising for example an enterprise server 121 (or a server intended for such functions). The enterprise server 121 communicates with a client 122 (operative system based driver or specific driver application) which is intended to receive a memory device 123. When memory unit 123 attached, security policies are transferred to it. The security policy is also provided to a user 102.

Fig. 6 illustrates one exemplary embodiment of the method of the invention. When a memory device is connected 601 to a computer, an application program (such as Single Encryption Platform (SEP) developed by CRYPTZONE) installed on the computer will check 602 if the memory unit is secured, i.e. encrypted, If the memory unit is not secured it will ask if 603 the user wishes to secure it. If it the memory is already secured, the driver on the memory may try to find out 604 if the computer is connected to a network it can contact a server containing information about the secured memory. The server may be company server or a security provider server containing information about the secured memory. The result of the communication with the server may result in different actions which will be described in more detail below.

Above steps may be reordered depending on the application.

If the user memory unit is not secured and the user does not wish to secure the memory unit, the procedure is finished 605. However, if the user wishes to secure the memory unit, the application program asks 606 for a key or password used to secure the memory. However, if the memory is secured the driver already installed on the memory will ask for the key or password. In one embodiment the user or an administrator may have provided or set up a profile (set of rules) to handle the memory unit, Based on these rules different protection methods 607 may be applied for handling the memory. These are described below. If there is a connection to the server information such as logs, revision history, permissions etc., may be transmitted 608 to the server.

Depending on the profile, information received from the server and the key or password the memory unit is handled 609, i.e. encrypted, decrypted, access denied or content deleted.

When securing data on the memory unit, different protection methods can be used as mentioned earlier. During the activation phase, the memory unit inherits the settings of the user when it comes to security attributes, such as protection methods. These settings are embedded in the profile database 9022 (Fig. 9). Other attributes that may take affect are: logging options, session timeout options and various memory behaviour options. These may be part of the security policy, and can be applied to the user centrally. During the activation phase, the memory 902 is prepared by the activating component (which may be the client 122 on the user's desktop or the driver 901 itself at a later stage) to uphold the encryption policy of the activating user.

When accessing the secured content9023 within the memory device, the user may have to enter a password manually each time he/she wants to access the information. The reason for this is that the memory unit logic does not have to hold any server connectivity logic or any connection to the users profile database on the client program 122 on the computer. Technically, when data is secured, it is encrypted, e.g. using AES256 with a strongly randomized 256 bit key or any other suitable encrypting algorithm. In this case, the key is placed in a so-called "key-holder slots", i.e. in a secured data's header. Each key-slot is then encrypted using said AES256 or any other suitable encrypting algorithm with the key related to a specific protection method. The key is a hashed version of the actual password, to prevent brute-force procedures. See Fig. 2.

A time lock feature may also be available for the memory unit, which is used to lock the device after a predetermined period. The protection methods as mentioned earlier may be applied one by one or in

combinations and are described in the following:

In custom method, the user sets a password.

In the private password method, a password is provided by the user (owner) of the memory unit which is entered when the USB memory device is encrypted for the first time.

In the master password method, the password works as a secondary password, and may be provided when by an administrator of for example a company or by the user. The master password may override other passwords and managed by an administrator. The master password may be applied to every user

In the secure group method, a secure group password is provided by an administrator and is assigned to members of a group to allow access to the USB memory device or portions of the memory of the device by these members.

The enterprise password is randomly generated by the client or driver 901 when used. The password is communicated to the server, along with meta-information describing which users that should have access to the key and what role they should have when the key is used to access secured content. Possible roles may be:

• No access: No access is permitted

• Read: Only reading the content of the memory permission

•Contribute: Read and write permission

• Manger: Read and write and permission to change "permissions"

• Admin: Administrator rights.

In one embodiment, when a secured USB memory device is configured to utilize the enterprise password-protection method, and a user attempts to access the memory, the driver logic on the memory device attempts to locate the server. If the server is located, the user may be automatically authenticated, for example using operative system's (such as WINDOWS, LINUX, MAC OS etc.) built-in authentication mechanisms to provide credentials manually, e.g. using a login/password dialog. Once authenticated, the driver will query the server for the key that was used to secure the area. This means that the server acts as a gateway to access the information on the secured area. The server evaluates the meta-data related to the key to evaluate if the authenticated user should have access to it, or not. If access is granted, the key is handed out and the user can access the encrypted memory unit.

The recovery password method is generated by the client when applied to the secured memory 902. The key-generation is based on a seed that is provided to each user by the server upon server initialization. Each user in the company typically has a unique seed for this purpose. This indirectly means that each user's recovery password will be created differently for each user. The key generation logic also uses a random factor that in turn ensures that all keys for a single user are unique per secured memory 902 (or parts of it).

The recovery password operates in following way, see Fig. 3: 1. A file or USB memory device is secured. An id will be assigned to the key-slot that holds the key used to secure this entity. This ID is called the key identifier (in the figure marked as Content ID).

2. The Enterprise (centrally administrated) user ID is considered as user identifier, e.g. stored in user profile data base 30. The enterprise a general term comprising components such as the server, an administration tool and the client.

3. The user's recovery password (e.g. hosted by an enterprise server 32) is

considered as recovery seed 31.

4. The key that will be used to encrypt the file or USB memory device will be a hash, for example, with the factors key identifier, user identifier and recovery seed combined.

5. If the password is lost:

6. Optionally, any user will receive information on how to contact a support in case of lost passwords, when he is trying to access the file. The user follows the instructions and contacts the support.

7. The support using an Admin tool goes through a "lost password & recovery

password" routine.

8. Once authenticated, the user states a "recovery ticket", which is the user

identifier combined with the key identifier, e.g. separated by a character (such as "-"). The user will be able to see this information amongst the information on what to do if the password is lost. For example, the recovery ticket might be "3243- AA443210" - where 3243 is the user identifier, and AA443210 is the key identifier.

9. The support enters the recovery ticket in the admin tool wizard, and the user that is the owner of the recovery password used at the time of encryption is displayed. 10. The support authenticates (done verbally or in written form) the user calling in, and if they are satisfied with the authentication he or she clicks next.

1 1. The recovery password used for the specific content will be displayed at the

support desks screen, whereas it is communicated to the user. According to a preferred embodiment, there may be three components to a recovery password:

User identifier: (e.g. 32 bits) ID of the user on the Enterprise Server

Key identifier: (e.g. 32 bits) ID of the key-slot that has the key to unlock the Secured File/Folder/USB memory device

Recovery seed: (e.g. 128 bits (variable)) The actual seed that will be generated and stored by the server.

Recovery ticket: A string value that is a concatenated string result of the user identifier and the key identifier (for example "00078-FEAB0002").

The final recovery key is generated as follows:

SHA1 (user identifier || key identifier || recovery seed), which will result in, for example 160 bits of data. The recovery ticket will be encoded in a way so that it is user-readable and communicated easily in written or verbal form. See Fig. 4. When the server processes the recovery ticket, it will retrieve the id of the user (User identifier) and the key identifier. Using the user id, the server will retrieve the recovery seed used. The server will then process the user id, the key identifier and the recovery seed in the same way as mentioned above using, e.g. SHA1 , to re-create the recovery password.

According to one embodiment of the invention, it is possible to authenticate the user toward the server to access a key to be able to access the device, which opens up Single- Sign-On (SSO) values. Every action performed with the secured area on the USB memory unit can be logged inside the secured area, see Fig. 5. This includes, deletion of files, un-securing files, securing files, changing password etc. The log procedure, which also may include a content revision, logs all transactions, i.e. copying, deleting, adding, making changes etc., on the memory device, the user computer and/or the server. All transactions are provided with a serial number or id. The logs are usually but not exclusively transmitted and stored on the server whenever possible by means of driver of the memory device.

The logs are accessible for browsing if one has access to the secured area or the server (after synch-processing). It is done by opening the secured area in browser mode, going to the main menu and select, e.g. display log-browser. This allows to determine e.g. if a specific file (data set) existed on a memory at a given time.

The present invention allows enforce encryption on all data placed on the USB unit. The aim for this is to create a way so that data can not be stored as plain text on an USB unit that has a secured area. This feature can be policy controlled through settings:

• Allow user to store unsecured data on the USB memory device

• Automatically detect if unsecured data exists outside the secured area, and ask user to secure it.

· Do not allow user to store unsecured data on the USB memory device

One aspect of the invention may involve policies which can be decided centrally. A policy contains settings. A policy can hold one or more settings. One or more policies can be applied to a user or a group of users. Merging rules are in use to define the final settings to be applied to a user. This adds great flexibility to the product and gives the

administrators the chance to configure the policy settings in the way they want.

Thus, this is an advantage that the policy handling centrally may have single policies applied to a single user or group, or multiple users or/and groups as well as multiple policies apply to a single user or group, or multiple users and/or groups. Furthermore, a policy might consist of a single system setting as well as many. Moreover, a setting does not have to be unique between the policies, as conflicting rules apply.

In one embodiment the administrator may have the possibility to choose a "list" of policies for the users and rank each policy in the list. The higher rank a policy has means it will override the policies with a lower rank. This is only the case when the two policies have settings that conflict with each other.

Example:

Policy A has some settings defined for email securing and file securing. Policy B has some settings defined for email securing, Password and Admin Lock. User is applied both Policy A and Policy B, with Policy A as higher rank. The user will get the settings for email from Policy A since it has higher rank than policy B. However, he will get Password and Admin Lock settings from policy B since these settings have not been defined in pined in policy A.

Fig. 7 illustrates the encryption procedure for the USB memory 70 according to the invention. The USB memory comprises a security driver application 71 (901 in fig. 9) and a database located in the flash memory location 72. The client application 76 on the receiving device such as a computer 75 is activated. Once the driver application 71 is accessed, it will authenticate the user using a password prompt. The end-user processing commands on the computer 75 using the interface provided by the driver application 71 will then be able to secure and unsecure data to and from the USB memory device. The secured data is stored in the USB memory driver location 72.

In one embodiment the invention allows a user or administrator remotely blocks access to the USB or delete the data on a secured USB memory device. When a lockdown is issued on a secured USB, the USB will be blocked from further access until the lockdown is removed. When a delete is issued on a secured USB, all the data on the device along with the secured USB executable will be wiped and the data may be unrecoverable. Fig. 8 illustrates the schematic of this embodiment. When a user connects a USB memory 80 to a computer 85 to access data on the USB, the driver application (as described earlier) on the USB memory is configured to contact a security server 82, e.g. enterprise server (as described earlier), through a communication network 83, Internet or Intranet. In a lifecycle parameter of the device a system administrator may initiate options for lockdown or delete. These are stored in a database 84 communicating with the server. When the USB memory contacts the server, it receives the command and the driver application executes the command, i.e. decrypt data, lockdown (deny access to data) or delete data.

This function allows taking control of the USB, which may have been lost

When a lockdown or delete command is issued for the device, the command may be in a pending state until the command has been communicated to the device. After that, the administrator may be able to see that the command has been successfully delivered to the device.

According to one embodiment secured USB memory devices which have not been synchronized with the server for a given number of days can be made inaccessible to the user.

Some companies, for example, may require that their users synchronize their secured USB memory devices regularly. This provides companies to enforce their employees to synchronize the content logs of their USB memory devices with the server.

This is possible through a setting added in the policy editor to enforce this behavior. A secured USB memory device that has not synchronized with the server successfully for a given period will not be accessible until a successful synchronization takes place. This is achieved in same way as the forgoing example. A parameter for force

synchronization may be sat when the USB memory device is secured. The driver application controls this parameter each time the secured USB memory device is accessed. When the secured USB memory device has not been synchronized for a given time period, the access to the secured USB memory device may be blocked.

In one embodiment, the driver application on the receiving computer can upgrade the driver on the memory unit. When a secured memory device is inserted in the computer where the driver122 is installed, the driver 122 evaluates the contents of the memory unit to determine if it the driver on the memory can be upgraded to a newer version. This provides the ability to correct logic errors on the memory device. In yet another embodiment, an integrity check mechanism may be applied which based on the revision and log mentioned earlier a stick can be found 'damaged' and become repaired.

It should be noted that the word "comprising" does not exclude the presence of other elements or steps than those listed and the words "a" or "an" preceding an element do not exclude the presence of a plurality of such elements. It should further be noted that any reference signs do not limit the scope of the claims, that the invention may be

implemented at least in part by means of both hardware and software, and that several "means", "units" or "devices" may be represented by the same item of hardware.

The above mentioned and described embodiments are only given as examples and should not be limiting to the present invention. Other solutions, uses, objectives, and functions within the scope of the invention as claimed in the below described patent claims should be apparent for the person skilled in the art.

Claims

1. A memory arrangement (70, 80, 90) comprising a security driver application (71 , 901 ) and a storage portion (72, 902), said driver application (71 ) being configured to, when accessed, to authenticate a user using an authentication procedure and secure and/or unsecure data on said storage arrangement characterize in that said memory arrangement is configured to execute an application being part of memory encryption policy and applicable by a central controlling system and the driver application is further configured to, based on said authentication procedure take an action being one of: · provide access to said data,

• deny access to said data,

• delete said data stored in said memory arrangement.

2. The memory arrangement of claim 1 , wherein said memory accessing arrangement (75) comprises end-user processing commands used to access said data.

3. The memory arrangement of claim 1 , wherein said memory arrangement is one of a USB (Universal Serial Bus) memory unit, digital camera, digital video recorder, Personal Digital Assistant (PDA) or a cell-phone.

4. The memory arrangement of claim 1 , configured to be connected to a host by means of one or several of a USB bus, FireWire (IEEE 1394), Human Interface Devices (HID), PCMCIA, Bluetooth or Infrared.

5. The memory arrangement of claim 1 , using an application on a host configured to guide a user and function as a link between the user and the memory arrangement.

6.

6. The memory arrangement of claim 1 , wherein a user deployment configuration comprises one of: securing memory arrangement manually, enquiring to secure memory arrangement once for each device, enquiring to secure memory arrangement every time an unsecured device is used.

7. The memory arrangement of claim 1 , wherein said memory arrangement is further configured to block said data if a synchronization process in absent of a synchronization procedure within a specified time period.

5

8. A method of policy based security deployment for a memory arrangement, using a first operation level (10), a second policy level (1 1 ) and a third component logic level (12), whereby an administrator (101 ) administrates said deployment policy of the second level, whereby the security deployment is transferred to said third level, in which a server (121 )

10 communicates with a client (122) which is intended to receive said memory arrangement (123), and when said memory arrangement is received, security policies are transferred to it, whereby upon reception of a command from said server by a the memory arrangement on said component logic level, said memory is arranged to grant access to or deny access to or delete data on said memory arrangement.

15

9. The method of claim 8, wherein when data is secured it is encrypted using suitable encrypting method.

10. The method of claim 8, further comprising a time lock feature used to lock the

20 arrangement after a predetermined period. . The method of claim 8, comprising a recovery procedure operating as a secondary private password.

25 12. The method of claim 11 , wherein said recovery password operates:

β assigning an id to a key-slot that holds a key used to secure the arrangement, e storing a centrally administrated user id in a user profile data base (30), e using user's recovery password as a recovery seed (31 ),

providing a key used to encrypt said arrangement as a hash,

30 If the password is lost:

o authenticating the user, and

35 o using the recovery password for un-securing a specific content,

13. The method of claim 12, wherein said hash comprises a key identifier, user identifier and recovery seed combined.

14. The method of claim 13, wherein said recovery data is the user identifier combined with the key identifier.

15. The method of claim 14, wherein a final recovery key is generated using: user identifier, key identifier and recovery seed.