Secure Remote Key Storage

AUTHOR’S PREPRINT – FINAL VERSION AVAILABLE IN PROCEEDINGS OF INFORMATION SECURITY SUMMIT 2014 1

Secure Remote Key Storage

Selected design principles of a security architecture and experience from cooperation between a university

laboratory and a commercial company

Martin Hanzal <[email protected]>, Petr Švenda <[email protected]>

1 Abstract

The article analyses the problem of secure storage of passwords and cryptographic keys in programs and web

services used as electronic “key cases” (KeePass, RealPass, LastPass, Mozilla Sync…). An overview of basic

principles and limitations is provided together with practical examples of actual attacks which were successfully

carried out against individual services recently. Design principles of new open security architecture for more

secure storage of sensitive information are presented. Practical experience from more than two-year long design

and development of the security architecture between an academic institution and a commercial company are

also summarized.

2 Introduction

Authentication using a password is a long used system with very well-known advantages (in particular simple

implementation and use) and disadvantages (the length of a password is limited by a user’s memory, frequent

choice of weak passwords, sharing of a password between several services, recording of a static password by a

keylogger) [1].

There is a whole range of other options of authentication which can be substituted for passwords, starting with

other methods which use something the user knows (this is again restricted by similar constraints of a user’s

memory abilities), through methods based on the ownership of a certain object (e.g. an authentication calculator

or a smart card whose acceptance is made difficult by the reason of their production price and the distribution

logistics and complex use) and ending with biometric methods (which have, among others, the disadvantage of

being unable to verify liveliness in remote authentication) [1]. Static passwords therefore are going to remain a

widely used authentication mechanism in the near future.

The user is therefore faced with the requirement to choose typically dozens of different secure passwords. One of

the possible solutions is the use of applications generating a long secure password which are kept in a file on a

local device of a user (e.g. KeePass, Password Safe). The file is encrypted with a single password which the user

must remember – potential attacker needs to obtain not only password value, but also file with passwords.

Due to the use of more devices (a laptop, a mobile phone, a PC, etc.) storing the file with passwords in a suitable

central storage, e.g. DropBox, Google Drive, Microsoft SkyDrive, etc. represents a natural extension of previous

scheme. The database is then accessible from more devices. It is, however, a problem to access the file with

passwords in the absence of connection to the Internet. Although the file with passwords can be stored also

locally and a new version can be recorded in the remote storage after Internet connection is restored, this can

lead to inconsistency when more devices are used and therefore to problematic synchronization.

The synchronization problem is solved by specialized services focused on storing passwords (e.g. RealPass,

LastPass, Mozilla Sync , etc.), which do not provide only a flat storage of the encrypted file with the database. A

service is able to work with stored items individually and allows for more advanced synchronization and parallel

use between multiple user devices. As the stored file with passwords on the remote service is still encrypted with

a master password which is selected by the user, it is not necessary to trust this service that it will not misuse the

stored passwords or disclose them by mistake. Keys derived from the master password are typically used not

only to decrypt downloaded items, but also for an authentication with a service.

This model, however, fails if the user’s master password is not sufficiently secure as was shown by attacks on

these services in recent years. For example, in the case of the attack against the service LastPass in 2011, an

attacker gained control of data servers and copied database files encrypted with a user’s master password [2]. If

the user had a sufficiently strong password, the attack should not have a negative impact on him because the

attack would not be able to decode his database file and therefore also stored passwords. But as a study

conducted on the password hashes leaked in another attack against the LinkedIn service in 2012 [3] shows it was

possible to find more than 60% using brute force and dictionary attacks. If a similar security level is assumed in

passwords selected for encryption of database files in the service LastPass, private information of more than a

half of users is accessible to a possible attacker. Services storing these types of data are a very attractive target


for an attack. It is not only necessary to consider the weakness of passwords, but also the strength of an attacker.

If he has a database of hash passwords, he can attempt to carry out a fast, parallel search of passwords on a

specialized hardware or using cloud computational services. The time aspect is also important. Assume that an

attacker obtains a dump of encrypted database, but is not able to crack it yet. He can still wait a few years before

sufficient capacity is reached and then proceed with password cracking. As many users do not change their

passwords, decryption of database may make sense even after several years.

The series of internal documents from the American security agency NSA leaked by E. Snowden has shown

(among others) that large cloud service operators, which are typically operating in the USA, in some cases

consciously cooperated with intelligence services and handed data over to them. Although this was apparently in

compliance with the legislation, cases when they became unconscious targets of eavesdropping on internal

communication also occurred as in the case of communication between the datacentres of the companies Google

and Yahoo [4]. The value of the data and metadata stored in these data storage sites made these services again an

attractive target of an attack, whether a legal one according to the legislation (a court order) or not. These

revelations have resulted in high estimates of potential losses because of lower trust of users in cloud storage and

in discussions about the establishment of more localized services.

Another example of a specific attack is the case of compromising the database of cryptographic seeds used in

authentication tokens marketed by the RSA company [6]. It was revealed that attackers did not only gain access

to information about the user database but also to cryptographic seeds which can be used to predict values

displayed at a given time interval by RSA SecureID authentication tokens. The compromising led subsequently

to a successful attack, for example, against the company Lockheed Martin [7].

2.1 Weak Points of the Existing Systems for Password Storage

The above given text describes specific real cases of a failure in the security of the existing systems. On their

basis it is possible to deduce certain typical errors or not adequately considered factors in the assumptions of

designers of these systems.

It is assumed that the user selects a strong password. If the data on a remote service are encrypted with a

user password, the service or an attacker who compromises it may attempt to guess this password by brute

force. The statistical data of the password strength from different leaks suggest that more than half of users

do not choose a sufficiently strong password.

It is assumed that the user selects a unique password for every service used by him. Users often share a

single or only a few passwords between multiple systems. The leak of one password (whether by disclosure

at the user, e.g. by a keylogger, or as a result of a successful attack on the given service which does not store

the verification password sufficiently securely) can lead to compromising of others non-associated services

even if these services process passwords in a secure manner.

It is assumed that the computer and storage environment on the part of the service operator cannot

be compromised. Although there is a constant rise in awareness and efforts to secure internal networks and

storage against attacks, due to the existence of very advanced and well financed attackers it can be presumed

that every sufficiently interesting target can be successfully attacked and the data stored on it can be

compromised. Absolute trust in the security of a remote service is therefore unfounded. Apart from attack

prevention, detection and timely reaction is also important, including a possible recovery after an attack. The

less an attacker may gain by compromising a service, the lesser his motivation to attack it is.

The possibility of long operation without compromising is assumed. All or nothing mentality. Storage of

passwords in a single place (even though it may be potentially very well protected) results in a mass

compromising of all stored information in the case of a one-time successful attack. Moreover, a common

user may never know about the compromising. For example, infection of a user computer containing a

password database (e.g. KeePass) and interception of a password for decoding this database makes all stored

passwords immediately accessible to an attacker. A transfer of the database to a remote storage out of reach

of the attacker enables an additional access control and an additional analysis of the typical behaviour with a

possible notification of the user on any unusual activity in a similar way that banks carry out analysis of

suspicious payment transactions. The remote service may not allow even a correctly authenticated user to

gain the entire password database at once, but instead give him only a limited number in a given time

period. Local storage in a file system does not offer this option without the support of additional hardware

(e.g. a smart card).


It is assumed that the access recovery mode has appropriate security. A frequent method of attacking an

authenticated service is the use of the access recovery mode. Although the access recovery mode should

theoretically use authenticating information at the same security level as the standard access, in practice this

is frequently not the case. A widely used mechanism for access recovery is resetting a password by means of

an additional email address to which the original password or a link for the option of setting a new password

is sent. Typically the user does not realize this interconnection and may not pay so much attention to the

security of his email as to the original service. Due to the trend of owning a single central email address

(“One account. All of Google”) and keeping all past correspondence (“to keep giving people more space

forever.”, GMail) including registration emails, a successful attack which makes this email box accessible

leads to a cascade of requirements for access recovery to services used by the user. Another case are

additional questions, and although these can be chosen as very secure, the typically offered variations of the

“Maiden name of your mother” type make the user choose the less secure variants. In addition, the user may

not be informed of the existence of certain recovery mechanisms, e.g. the use of the last four digits of the

credit card number, which a different service makes freely public [10]. Service operators typically prefer

easy recovery over security for the end user. The number of forgotten passwords is significantly higher than

the number of targeted attacks and most requests for recovery therefore really come from legitimate users. A

failed recovery represents an additional burden for the technical support employees and leads to unsatisfied

users. A good example is the recent attack aimed at acquiring the attractive user name @N on Twitter. The

attacker obtained the last four digits of a targeted user credit card from the PayPal and the hosting company

GoDaddy let him to guess further two digits which was enough for starting the process of transferring the

domain owner [8].

It is assumed that a service is interested in providing the best possible security of data for a user.

Information stored and processed by a user represents a valuable source of data for a service operator (e.g.

for marketing needs). It may therefore not be in the operator’s interest to store the data in such a way that he

cannot access them in their open form. For example, in the case of storing passwords the motivation of the

operator will not be to store the open form of the passwords, he may be interested in attached metadata

instead – e.g. the frequency of password use connected to the given user name and address.

It is assumed a service handles a password for authentication securely. In spite of the existence of

recommended procedures for verification and storage of authenticating information, an entire range of

wrong procedures are used on the part of a service operator. E.g. keeping the direct value of an

authentication password on the target service makes possible to send the original value of a password during

a recovery, but at the same time leads to leaked password value when an attacker compromise a service.

Insufficient salting in the case of hash storage is another common mistake as it enables significant

acceleration of an attack using pre-computed tables – the so-called Rainbow tables [5].

It is assumed that diverse authentication channels are independent. Two-factor authentication

introduces an additional authenticating channel, typically by means of a mobile phone. If the user’s device is

for example a smart telephone, both channels can end in the same device and are therefore dependent.

Correct implementation and observance of prescribed procedures are assumed. Errors in

implementation will always occur and they can lead to disclosure of data stored on a remote service.

Similarly, a failure to observe assumed procedures, e.g. as a result of successful social engineering. The

fewer data which can be abused are present on a service, the smaller the impact of possible compromising is.

3 Basic Principles for a More Secure Architecture

The above given text has provided us with a basic framework for the design and development of a new security

architecture which attempts to solve the described problems. We will give a list of basic principles which enable

progression to a more secure solution and at the same time we will add practical experience from their

implementation. The design and development process took place in cooperation with the security laboratory

CROCS at the Masaryk University and the company SODATSW.

In terms of functional requirements the aim of the design was to develop a universal secure web service for the

storage of shorter secrets (passwords, keys, and shorter data) with a focus on regular home users with no

advanced knowledge, abilities or additional equipment. The service should, however, be also usable in a

corporate environment and it should therefore support batch operations from trained users with more advanced

operation skills. The offered functionality from the point of view of the user should be similar to the

functionality in systems for management of passwords and other secrets, like for example in LastPass [9]; it

should moreover support controlled sharing of stored secrets in a virtual group of users. A parallel access from


various users’ devices (a laptop, a mobile phone, a home PC) is assumed. It is assumed that every user has got

own mobile phone and an email box.

In terms of security it was required that the design significantly increases the resistance against the weak points

identified in section 2.1, while at the same time not increasing the requirements on the knowledge and technical

equipment of the user.

The following text first summarizes the considered attacker model and then it presents key design principles of

the architecture including their short security analysis.

3.1 An Attacker Model

The following types of attackers were considered within the framework of the analysis according to their

abilities:

1. An attacker able to eavesdrop on / modify traffic on the network: an attacker of the Needham-Shroeder

model

2. An attacker with a one-time access to data stored on the Service: e.g. copying of a database after one-

time compromise of a server

3. An attacker with an active access to the Service: e.g. a compromised employee of the Service operator

4. An attacker with a one-time / active access to the Key Service

5. An attacker with an access to one of the authenticated devices of a user: an unlocked computer,

malware on a computer, etc.

6. An attack with a physical access to an authenticated device: physical misappropriation of a computer

without access to login data

7. An attacker with an access to an authenticated device and a telephone of a user: e.g. misappropriation of

an iPhone which functions both as a telephone and an authenticated device

8. An attacker with a one-time access to a phone of a user: an unguarded phone till 1 hour, a possibility to

read older text messages, a possibility of initiating a communication with the Service from an attacker’s

device

9. An attacker with a stolen (accessible) phone: a stolen phone without additional security (PIN)

10. An attacker knowing user’s Password

11. An attacker with knowledge of information for access recovery in the case of a loss of primary access

information

3.2 Basic Principles of the Architecture

The most important feature of the new design is the development of a mechanism for storage of sensitive data

(passwords, etc.) on a remote platform (Service) in which even a choice of a weak password by a user or its re-

use in an unrelated service will not lead to compromising of the stored passwords. Research has repeatedly

confirmed that both cases are common among regular users and they must be taken into consideration. If the

design is executed in such a way that even in the case of a weak password, the Service operator (e.g. an

administrator) cannot gain access to the user’s data. From the point of view of the user only low level of trust is

required with regard to the Service in terms of keeping the stored information secret. This reduces the motivation

of both internal and external attackers to attack and compromise the Service (e.g. by copying the stored password

database for all users and by subsequent search for weak passwords). A range of attacker models presupposing

compromising of partial elements of the system was considered in the frame of the analysis and a system of

dividing all used cryptographic keys was designed so that at no moment will partial compromising in the system

(e.g. Service) lead to accessing the stored passwords of a user. Meeting this principle, however, requires

significant changes in the previously simple access “Log in, download, decode and use a password”.


Figure 1: Basic entities in the designed system

Division of the server part into two entities operated by independent subjects

In the framework of the server part of the system we distinguish two entities – the Service and the DD Service.

The Service contains the stored passwords of the user and it is the primary communication partner for the user

and his device similarly as in the case of services of the RealPass type. The DD Service contains a part of the

information which the user needs for adding a new device or for recovering access. The user communicates with

this DD Service only sometimes and the DD Service has a very limited interface for reducing the attack surface.

This division aims at minimizing the impact of possible compromising of a part of the system. If an attacker

gains control over one of these entities (e.g. successful control of the Service server), this attack does not lead to

gaining the open form of stored passwords. The stored data obtained by the attacker are encrypted with a key (or

in a practical implementation with more keys, for the sake of simplicity let us consider only one key with the

designation K) which cannot be attacked with brute force due to its length. Similarly, a dictionary attack on

potentially weak passwords of users does not lead to decoding the data, because the K key is composed of a user

password only partially and it is supplemented by other data with high entropy originating from the DD Service.

In a successful attack, both of these entities would have to be compromised simultaneously. The risk of

compromising the DD Service is moreover minimised by the use of a much reduced API which can be used only

by the Service. The Service and the DD Service should run on separate physical machines in order to improve

the security. The DD Service does not have to be accessible from the Internet network, but only from a limited

scope belonging to the Service.

The Service cannot attack with brute force on Passwords or short keys

Nothing which would be protected only with a weak key (i.e. less than 128 bits of entropy), or only by a user

Password (which can be chosen as too weak by the User) is stored on the Service. This eliminates the possibility

of a successful attack by a brute force on the part of the Service itself, e.g. by an internal attacker. The risk of an

attack on the Service by an external attacker is also limited because unprotected data or data which can be easily

attacked are not stored on the Service.

A user’s Password alone is not enough for an access

The user’s Password alone is not enough to access the values of stored passwords. As the Passwords selected by

the user may be potentially weak, the system uses an additional token (binary data not physical devices of the

smart card type) stored on a user device for authentication and access. A combination of a stored token and a

Password is always required for accessing the Service and the secrets stored on it. If an access device of a user is

compromised by a generic keylogger, a complete compromising of the system does not occur. Only the

Password which on its own is not enough for accessing the data on the Service is compromised. There remains

the possibility of compromising both the Password and the token after which the attacker may access the

Service. For this case every user’s device is assigned a unique token and if compromising is suspected, the given

device can be blocked by invalidation of the specific token. If, on the other hand, the user chooses a sufficiently

Service DD Service

User profiles - access information - authorized devices Groups - access information - shared Secrets

User profiles - identification information - phone number - derivative data

Authorized device

- access information

UserID Password

Text message

Secure channel

Secure channel


strong password, compromising of other used secret information does not lead to compromising of stored

passwords.

Only temporary secrets are stored on a mobile phone

A mobile phone combined with an entry from the user is used for adding a new user’s device or recovery of

access. At no time does the mobile phone contain any authentication information which may be used for a longer

period of time so that this information cannot be abused in the case of loss/theft. This is why long-term

derivative DD data are transported into the user’s PC through an encrypted channel via the Service. Only

temporary data which protect this encrypted channel are sent to the mobile phone.

Every user’s device contains different login data

Different unique data for authentication on the Service and acquiring keys necessary for accessing stored

passwords are on every user’s device. The aim is to enable a distinction of various devices in performed

operations for the purpose of supporting the analysis of suspicious operations and selective revocation of a

device in the case of a suspicion that it is compromised.

The Service does provide encrypted data without prior authentication

The correctly behaving Service does not provide user’s encrypted data to a third unauthenticated party. Although

the data stored on the Service are always encrypted, their value is sent only after successful authentication.

The system provides two different modes of access recovery

The weaker recovery mode requires a registered mobile phone and a recovery key for access recovery. This key

may be stored at an agent for recovery with a lower level of trust because this key on its own is not sufficient for

access recovery. On the contrary, the strong recovery mode requires only the key for recovery and this key

should be entrusted only to a trustworthy agent for recovery, e.g. to a notary. The design intentionally leaves

open the possibility of representing and storage of the key for recovery so that a suitable approach, e.g. a smart

card, can be used if the user owns it or a threshold cryptographic scheme for assembling keys from multiple

parts.

The system supports sharing of data in groups with controlled access

The users can interact with each other and share selected data in the framework of groups. Apart from the

standard access control by means of rights it is necessary to solve operations of the adding of new information

type and its change even in the case when most users cannot cooperate in real time and the completion of the

operation must be solved by means of asynchronous performance of requests. A more free time sequence has an

impact on the order of executed actions and the level of trust in individual steps at a moment when, for example,

a certain user stops being trustworthy and he is excluded from the group.

Use of validated cryptographic standards

The designed architecture requires certain new design principles for which there are no standardized

cryptographic protocols at present. These can be, however, assembled from standardized verified cryptographic

schemes. The designed architecture uses derivation of keys PBKDF2 using RFC2898, a GCM mode for

authenticated encryption using NIST SP 800-38D, digital signature RSA + SHA2-512 using RFC 3447 PKCS

#1, Cryptographic Message Syntax (CMS) using PKCS #7, OATH Challenge-Response Algorithm using RFC

6287 and a secure channel using SSL.

3.3 Life Cycle of Use

The life cycle of the designed architecture includes the following steps:

1. Operator 1 installs and starts the Service, Operator 2 starts the DD Service.

2. All participating persons (users) register themselves on the Service and the DD Service. A batch pre-

registration of users by the administrator, which can be used, for example, in a corporate environment,

represents an alternative.

3. A participating person adds at least one authenticated device using its Password and mobile phone on which

it receives a part of the authenticating information from the DD Service.

4. The user logs in from the authenticated device to the Service and he can create a new work group in which

he becomes an administrator. He can then invite or remove users from the administered group.

5. Data fields for entering sensitive information (typically passwords and keys) with different visibility for the

group members are then created within the framework of the group.


6. The architecture supports additional operations for the change of the user’s data (passwords, new keys,

access rights, etc.) and handling of users in groups, group properties and passwords and keys stored in them.

4 Usage Options of the New Architecture

The designed architecture functions as a secure storage of passwords and keys to which applications using the

stored passwords and keys connect. We deal with two examples of these applications in this section.

The first type represents the use of secure storage of keys for applications offering file or disk encryption of user

files. The user files may be stored locally or on remote clouds, e.g. Skydrive, Google Drive, Dropbox. The user

requires an access to encrypted data stored on a remote cloud from various devices – from a computer/laptop, a

tablet or a mobile phone. All user’s devices share an encryption key so that the encrypted data can be decoded. If

the encrypting application uses the services of a secure remote storage of keys, it does not have to solve the

management, back-up and possible emergency recovery of the encryption key because these applications are

already provided by the designed architecture.

The second example of the possible use is secure sharing of encrypted data among more users, e.g. within the

framework of a group of users or between an organization and a user. Every user who wishes to share the

encrypted data makes an account on a secure remote storage of keys. The users may form a group of users with a

shared encryption key and use this encryption key in exchanging the encrypted data between the group members

or in the framework of encrypted data storage. One or more group administrators may add or remove group users

and thus determine who has the encryption key of a relevant group. The use is made easier because the users do

not have to exchange encryption keys between themselves and the entire process is automated within the

framework of the secure storage of keys. In this way it is possible to create also encrypted communication and

exchange of encrypted data between an organization and its clients, e.g. for sending encrypted messages or

documents.

5 Experience from Cooperation between the Company and the University

The security architecture has been in development for more than two years in the framework of cooperation

between the research university laboratory and the commercial company. University laboratory was responsible

for designing the frame of the secure architecture and the specific cryptographic mechanisms used for the

implementation. The company gave a continuous feedback on the priority of design requirements, practicability

of the scheme and user-friendliness of the designed operations. Due to the complexity of the designed

architecture and continuous changes during the design it was necessary to verify the validity of all requirements

in the prototype implementation. The development and continuous updating of the “shell” prototype

implementation which abstracted from the implementation details which were still not known at the given time

proved successful. For example, a specific encryption mode was temporarily substituted for by inserting a string

value containing information on the used encryption key. The receiving party can thus verify that it owns the

used key at the given moment and that there is no inconsistent state in the architecture design.

A key factor is also the existence of a contact person on both sides who participates in the design and the

verification of the functionality with regard to the requirements for the entire time. Due to the scope of the

designed architecture this person must have not only very good technical skills but also communication skills.

The significance of continuous development of very detailed documentation also became apparent. Although the

created documentation sufficed for the execution of practical implementation on the side of the commercial

company, it had to be further expanded in order to carry out an independent security audit. Documentation of

parts which diverged from the standardized procedures constituted a very important element.

Another important factor influencing the cooperation are different possibilities of allocating working time in the

university and company environments. Due to other workload (typically teaching and research) university

employees prefer mostly long-term workload divided into smaller parts. A company, on the contrary, prefers

short-term intensive solution of one project. A partial solution is to transfer the core of works to the company as

fast as possible and to attempt to make partial tasks run in parallel. Due to frequent changes in the design of the

architecture during the initial stage the possibility of parallelization is limited.

Gradual transfer of the activity from the university to the company represents also an important element in the

cooperation. A typical problem is the gap between the state in which the design is prepared for transfer to the

company from the point of view of the university and the state in which the company is willing and able to fully

accept further development and implementation. Participation of the company employees already in the initial

stages, not only for providing input requirements but also for maintaining a permanent detailed vision of the

current state of the architecture, constitutes a suitable approach. On the contrary, the approach to wait for the


complete documentation of the architecture on whose basis the company then began the practical

implementation proved to be unsuitable.

5.1 Motivation of the Company for Cooperation with the University Laboratory

The SODATSW company has at its disposal a high-quality development team which has gained considerable

experience in implementing encryption technologies on diverse levels during its seventeen years of activity.

These implementations included also functions for the management of encryption keys including their sharing

among users. The design and implementation were, however, always discussed within a closed in-house

environment with a high level of trust in the central servers. They are used for generating encryption keys, their

storage in the depositary, distribution among users and control of recovery and emergency states. The processes

take place within a trustworthy environment of the organization which controls and requires the encryption tools.

This assignment does not apply in the case of a newly designed secure storage of encryption keys, because it

intentionally does not rely on the trustworthiness of the provider of this service – an assumption which was right

from the beginning clear to be the key for a successful use of the architecture. After performing the initial

research it was found out that architecture with these parameters is not available and it was decided to design and

develop it.

The possibility of developing this architecture within the framework of the internal development team of the

company was quickly rejected. The main reasons for doing so were as follows:

The team has experience primarily with applied development and not with a design which requires also

academic research.

The design would have been done by one, or at most two developers.

The design would lack abstraction from real problems.

Current practical experience would excessively intervene in the design.

Due to this it was decided to form a team which would comprise both of academicians and an architect and a

product manager from the company. The academicians were to conduct research and assessment of the current

situation and to design architecture for secure remote storage. The team members from SODATSW were to

watch the boundaries which had been approved at the beginning. It was exactly this distribution of roles that

resulted in the fact that the designed architecture respected the initial requirements and the proposed boundaries.

At the same time enough space was left for considerable abstraction on the part of the university laboratory

which is essential for the design of a general architecture with a potential long-term use.

6 Conclusion

Although the disadvantages of using passwords have been known for a long time, it has so far proved impossible

to successfully replace all passwords with another better solution. Due to the extensive number of independent

web services which are currently used by an average user, it is not feasible to assume a selection of a sufficiently

secure and at the same time different password for every service without additional support, e.g. use of password

managers. The use of multiple user devices is a source of further complication for the synchronizing of stored

data. The central storage of stored passwords on a remote service by more users, however, increases the

motivation of an attacker to compromise such a service.

The article summarizes typical problems of the existing solutions for storing of passwords and describes basic

design principles of new security architecture for central storage of short secrets of the password and key type.

The key element of the architecture is storage of data on a remote service in such a way that their acquisition

would not lead to compromising even if the user chose a short unsuitable password for their protection. Both an

internal and external attacker has therefore reduced motivation to attack the service and to attempt to obtain these

data because an attack with brute force on a potentially weak password of a user will not result in a successful

attack.

The implementation of a service with this property is, however, not straightforward and it required long-term

cooperation between the university laboratory and the commercial company which initiated the development of

the architecture. The article also summarizes the experience from this cooperation.

Acknowledgment

The following persons significantly contributed to the design of the above described architecture: Vašek Matyáš

(management of the entire project on behalf of the Masaryk University, discussion of the architecture), Jiří Kůr


(design and discussion of the architecture), Petr Švenda (design and discussion of the architecture, coordination

of work with the SODATSW company, selection of specific cryptographic primitives), Vít Bukač (discussion of

the design, development of diagrams and documentation), Radim Ošťádal (selection and documentation of

cryptographic primitives).

On the part of SODATSW the following persons in particular contributed to the design of the architecture:

Roman Štěpánek (design, discussion and external examination of the architecture, program verification of the

scheme), Martin Ondráček (design, discussion and especially external examination of the design according to the

required assignment) and Martin Hanzal (project management on behalf of SODATSW).

7 References

[1] The quest to replace passwords: a framework for comparative evaluation of Web authentication schemes,

Joseph Bonneau, Cormac Herley, Paul C. van Oorschot, Frank Stajano, UCAM-CL-TR-817,

http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-817.html, 2012

[2] LastPass Users Urged to Change Their Last Password, Time,

http://techland.time.com/2011/05/05/lastpass-users-urged-to-change-their-last-password, available on 4

Feb 2014.

[3] LinkedIn investigates hacking claims, http://www.theguardian.com/technology/2012/jun/06/linkedin-

hacking, The Guardian, available on 4 Feb 2014.

[4] NSA Intercepts Links to Google, Yahoo Data Centers, http://spectrum.ieee.org/tech-

talk/telecom/internet/nsa-intercepts-links-to-google-yahoo-data-centers, available on 4 Feb 2014.

[5] OWASP, Insecure storage, https://www.owasp.org/index.php/Insecure_Storage, available on 4 Feb 2014.

[6] SecureWorks, RSA compromise: Impacts on SecurID, http://www.secureworks.com/cyber-threat-

intelligence/threats/rsacompromise/, available on 4 Feb 2014.

[7] PCWorld, Lockheed-Martin Attack Signals New Era of Cyber Espionage,

http://www.pcworld.com/article/228927/lockheedmartin_attack_signals_new_era_of_cyber_espionage.ht

ml, available on 4 Feb 2014.

[8] Naoki Hirosima, How I Lost My $50,000 Twitter Username, https://medium.com/p/24eb09e026dd,

available on 4 Feb 2014.

[9] LastPass service, https://lastpass.com/

[10] Mat Honan, How Apple and Amazon Security Flaws Led to My Epic Hacking,

http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/, available on 4 Feb 2014.

http://www.secureworks.com/cyber-threat-intelligence/threats/rsacompromise/

http://www.secureworks.com/cyber-threat-intelligence/threats/rsacompromise/

https://lastpass.com/


Martin HANZAL, Chief Technology Officer

SODATSW spol. s r.o., Horní 32, 639 00 BRNO

email: [email protected], tel.: +420 602 702 780

The author is a graduate of Computer and Information Technology at the Faculty of Electrical Engineering and

Information Technology of the University of Technology Brno, Czech Republic. He is a founder of the company

SODATSW spol. s r.o. which is active in the development and implementation of SW means for increasing the

protection of company data and information thus reducing the impact of threats originating from internal and

external attacks on information systems. Regarding his work in the company SODATSW spol. s r.o., the author

held the positions of a development and implementation director, a strategic development director and at present

he works in the company as a technical director. During his work he led a group developing patented solutions

for protection of data against theft by authorized users and implementation of security development certification

pursuant to CC EAL4 products for monitoring activities of users of an information system. The author has

practical experience with the problems of data and information protection from organizations with an extensive

organizational structure with thousands of employees as well as from companies ranging from medium-sized

organizations to family businesses and individuals. Since 2011 he has been a member of the NATO Industrial

Advisory Group for the field of Cyber Defence as a part of the leadership of NATO.

RNDr. Petr Švenda, Ph.D.

Faculty of Informatics, Masaryk University

Botanická 68a, Brno 602 00

email: [email protected]

Petr Švenda works as a security researcher at the Masaryk University, Brno, Czech Republic. He engages in

research in the field of authentication and key establishment protocols for distributed architectures with multiple

communicating parties or users, e.g. wireless sensor networks or remote storage of sensitive information. He also

analyses the practical security of cryptographic smart cards including the development of secure applications on

this platform. His research focuses on the possibilities of using evolution algorithms for an analysis of

cryptographic primitives. He devotes himself to the issues of secure programming using tools for a static and

dynamic code analysis. He participated in consultations and development for academic, state and industrial

organizations in the Czech Republic and abroad.

Secure Remote Key Storage

Documents

Transcript of Secure Remote Key Storage