Bdrive, Bundesdruckerei's cloud solution, allows you to share and work on data with others – both within your company as well as with external partners. You remain in control of the data at all times so that neither third parties nor Bundesdruckerei, the Bdrive operator, can access or manipulate your data. While developing Bdrive, Bundesdruckerei focused on both security and usability. In close co-operation with renowned research institutes working in the field, we have developed a high-security cloud solution that can also be easily integrated into your company’s IT systems.
As a high-security company with government tasks, we not only know about security standards but are also experts when it comes to compliance with legal regulations in national and international business transactions. This expertise is reflected in all of our products including in Bdrive which fully meets all compliance requirements.
In this document, we provides detailed information about the security measures implemented in Bdrive and the current status of external security evaluation. This will enable you to decide whether or not our solution can be used in conjunction with the security guidelines in place at your company.
The document is divided into the following sections::
All cryptographic methods used in Bdrive are recommended by the German Federal Office for Information Security (BSI) (see 3 and 4).In addition, the cryptographic procedures used in Bdrive are described in a ‘crypto concept’ that was developed according to BSI’s specifications.
The goal is to implement end-to-end security using cryptographic methods. End-to-end security ensures that neither third parties nor Bundesdruckerei can read or manipulate your data. Bdrive solely provides a solution to manage the users’ keys and the encrypted data.
The security functionalities described in this section are implemented by the Bdrive client software provided by Bdrive for the end-users’ devices. This software is currently available for Windows OS, and mac OS will also be supported from summer 2018. Versions for iOS and Android are in the planning stage.
Files, along with their names and hash values, are encrypted on the user's device. The encryption method used is AES in Counter (CTR) mode with a key length of 256 bits. In order to guarantee the authenticity of the data, a checksum is generated from the encrypted data using the HMAC-Sha256 method. Keys with a length of 256 bits are also used here.
The keys used are always generated on the user devices; they differ for each file and are additionally regenerated when the file is updated. A secure random number generator is used to calculate the keys (see also section 2.5). The same applies to the required initialization vectors used for theCTR mode.
All Bdrive users have RSA key pairs which are used to encrypt the keys for file encryption and authentication (we use RSA-EME-OAEP here). The RSA key pairs are also generated by the Bdrive client using the secure random number generator and have a length of 4,096 bits. RSA-EME-OAEP is a probabilistic encryption method and therefore requires random values, which are also provided by the random number generator described in section 2.5.
In order to enable not just the data owners but also persons authorized by them to access the data, the key for file encryption and authentication are also encrypted with the public RSA keys of such authorized persons. To ensure that only authorized users can access the keys for encryption and authentication, , all public RSA keys used in Bdrive receive a certificate from a trusted certification authority (see section 5.1). This makes it possible to uniquely assign the public RSA keys to the key owner.
The AES and HMAC keys can therefore only be decrypted by those persons who have been authorized to do so by the data owners. This also means that the files can only be decrypted by these authorized persons. In other words, even Bundesdruckerei, as the operator of Bdrive, cannot access the decrypted files.
When only one cloud storage service is used, this can result in a loss of availability if the service fails. To ensure a very high level of availability, Bdrive uses several independent cloud storage services to provide user data.
The encrypted data together with the checksum are divided into several fragments using an erasure coding procedure in such a way that only a few fragments are sufficient for recovery. For example, four fragments can be created so that only two fragments are needed to reconstruct the encrypted file including the checksum.
The fragments generated are uploaded to independent cloud storage services. If one (or more) of these services fails, the file can be restored despite the missing fragments. The number of generated fragments can be adjusted depending on the availability requirements.
Simply ensuring the availability of the encrypted file fragments is not enough. If, for instance, the key pair used to encrypt and decrypt the symmetric keys is lost, the corresponding data can no longer be decrypted. In order to meet with the availability requirements, each participating company generates a key pair and also has the public key certified, just like in the case of regular user key pairs. The respective symmetric keys for encrypting the data of the employees of the company are also encrypted with the company’s public master key.
These private keys must be protected accordingly. We recommend the use of Shamir's secret sharing method to transfer key parts to four persons, two of whom can assemble the company’s secret master key (four-eyes’ principle). The four key parts should be stored securely in external memory (e.g. USB sticks). Additionally, the availability of metadata should also be ensured (see section 2.3).
To manage the files on Bdrive, information about the file fragments is stored centrally in Bdrive. This information, also called metadata, is generated on the users’ devices and consists of:
Once the metadata has been generated on the user devices, this metadata is TLS-secured (mutual authentication always takes place, see also section 5.2) and uploaded to the secure environment of the Bdrive service where they are encrypted and stored with verified integrity in databases. Two redundant databases are used to ensure data availability. The contents of the databases are additionally saved daily on independent storage media.
Volatile keys, such as the symmetric keys required to encrypt the files, their names and hash values, are deleted immediately after use in the Bdrive client. The same applies to the secret parameters and keys used to establish the TLS connection. However, non-volatile secrets must be stored securely in the Bdrive client. These are:
The internal state of the deterministic random number generator The private key of the RSA key pair for encrypting and decrypting the symmetric keys (see section 2.1) The private key of the RSA key pair for user authentication (see section 5.3) Secure storage (i.e. encrypted and with verified integrity) of these secrets is based on a password. When authentication certificates are used, users must assign a device password in order to use the Bdrive client. When the GoID card is used, the password consists of two parts, one part of which is stored on the user's device. The second part is stored securely in the Bdrive service and transferred to the Bdrive client via the established TLS connection after the users have successfully registered.
Password-Based Encryption Scheme 2 (PBEC2) is used to encrypt these secrets and password-based MAC 1 (PBMAC1) is used to authenticate the keys (see 6). In both cases, a key with a length of 256 bits is first derived from the password and a salt using a so-called key derivation function (we also use PBKDF2 from 6). We use 100,000 iterations to derive the key within the key derivation function. This makes brute force attacks on the device password virtually impossible.
The salts are different (i.e. different salts for generating the encryption keys and the authentication keys), they have a length of 100 bits and are randomly selected once by the random number generator described in section 2.5.
The security of the cryptographic procedures and protocols used depends largely on the entropy (simply put, on the unpredictability) of the keys used and the other cryptographic parameters. Bdrive uses random number generators to generate these values, which are recommended by official bodies, such as the Federal Office for Information Security (BSI) and the National Institute for Standard and Technology (NIST) for use in highly sensitive areas.
The required random values are generated using the Deterministic Random Number Generator (DRNG) HMAC-DRNG from 7. The HMAC function is based on Sha256. DRNGs require a so-called seed from which they can calculate random values. In order to obtain a high entropy of the output random values, this seed must also have a high entropy.
The Bdrive client uses different values to generate the seed: user interactions (e.g. times during various actions and between keyboard strokes, mouse positions, system states, network traffic, etc.). The quality of these random values is proven in the external security evaluation.
The Bdrive service uses a physical random number generator to generate the seeds, which BSI has analysed and certified with regard to security for this purpose.
Files can be shared securely not only among staff of companies registered with Bdrive but also with external partners who are not registered with our service. Bdrive users can send files using linkshares and receive files using droppads.
Linkshares can be used to securely transfer files to employees whose companies are not registered with Bdrive. To do this, a password is first selected from which an encryption key and an authentication key are derived.
The file is then encrypted and authenticated with these keys and the encrypted file is securely stored in the Bdrive cloud together with an initialization vector, the checksum and a salt value. The recipients of the file receive a link which they can use to download this data. The connection between the browser and the Bdrive cloud is TLS-secured. Using the password, the file can then be decrypted and its authenticity checked. The decryption and verification of authentication take place completely in the browser.
We also use AES in counter mode here for encryption and HMAC-Sha256 for data authentication. Both keys have a length of 256 bits and are derived from the selected password with additional salt using the key derivation function PBKDF2 from 6. In order to practically prevent brute force attacks, we use 100,000 iterations within the key derivation function. All the required random values (initialization vector and the two salt values) are generated by the random number generator described in section 2.5.
The password can be transmitted via a secure channel (e.g. secure instant messengers such as Telegram or Signal).
Droppads are another functionality which users of companies not registered with Bdrive can also use to securely send data to Bdrive customers. For this purpose, the files are secured on the basis of the encryption certificates issued to Bdrive customers.
Two keys (for file encryption and authentication) and the initialization vector for encryption are generated in the user's browser. Both keys are encrypted with the public key contained in the encryption certificate and all the data (encrypted file, checksum, encrypted key and initialization vector) is securely uploaded to the Bdrive cloud. The file then appears in the Bdrive customers' droppad folder.
The file is encrypted and authenticated again using AES in counter mode and HMAC Sha256. To encrypt the two required keys, we use the asymmetric encryption method RSA-EME-OAEP as already described in section 2.1.
Secure implementation of the Bdrive service not only requires securing the individual systems, such as the Bdrive client, the Bdrive service, certification service provider and cloud services, but especially requires securing the communication between the individual systems. Besides encrypting communication via TLS, this also means authenticating the communication partners.
The basis for the secure exchange of data is that the communication partners must always be certain about who they are sharing the data with. To implement this requirement in Bdrive, all users receive authentication and encryption certificates. In addition to the users’ public keys, the certificates also contain the name, the company, the user ID and the issuing Certification Authority.
Authentication certificates are used for authentication in relation to Bdrive (see also section 5.3). Encryption certificates are used to encrypt the symmetric keys for file encryption and authentication for people who are to be permitted to access these files (see section 2.1).
High security requirements must therefore be met when these certificates are issued. All certificates are issued by D-Trust, an established and secure certification service provider (see also section 8.3). To ensure that the certificates can also be assigned to users, they must be clearly identified during the issuing process. This task is assumed by the respective company where the users are employed.
In order to implement the protection goals of confidentiality and authenticity during the transmission of metadata between users and Bdrive, the transmission is secured by Transport Layer Security (TLS). The data is therefore both encrypted and authenticated. The cipher suite DHE_RSA_WITH_AES_256_CBC_SHA256 is used here.
Both communication partners must authenticate themselves when the TLS connection is established. Bdrive authenticates itself to users via server authentication certificates which are also issued by D-Trust. Users have several ways to authenticate themselves to Bdrive (see section 5.3).
Bdrive authenticates itself to the users by means of server authentication certificates. There are currently two ways for users to authenticate themselves to Bdrive:
Using the authentication certificate issued
Using the GoID Card issued by Bundesdruckerei
Companies can decide for themselves which of these two options they want to use for the Bdrive service. Thus, they can adapt the authentication method to their required security level.
Bdrive processes the metadata of the file fragments. No conclusions can be drawn from this data regarding the file contents, however, it shows which users are working together on files. This information must therefore be protected confidentially. In addition, the platform must also ensure that any attempt to manipulate (protection goal: authenticity) or delete (protection goal: availability) the metadata does not go unnoticed.
Identity management is another important element of Bdrive. Users must be certain at all times who they are exchanging their data with. This is why the D-Trust certification service provider's platform has the protection required to prevent attackers from forging authentication and encryption certificates by intruding the system.
Bdrive and D-Trust use virus scanners and firewalls from various providers to protect themselves against external attacks. Virus signatures and configurations are regularly updated and adapted to the current security status.
These measures alone are not enough to protect the platform. This means, for instance, that so-called zero-day exploits (security holes that were previously unknown) cannot be detected. In order to be able to react to current attacks, we have implemented various intrusion detection and intrusion prevention systems on all platforms to detect attacks via anomaly recognition and initiate appropriate countermeasures.
What’s more, all activities are recorded and stored and regularly checked for anomalies by our security experts using established tools, so that system security can also be checked manually.
When developing software, we attach great importance to its quality in order to minimize security gaps that result from software errors. Our software undergoes several quality assurance tests before it can be used in the existing system.
We attach particular importance to the prevention of attacks with code injection. All input fields are clearly specified and are only processed further by the system if the contents correspond to the specification. In this way, we can prevent malware from being imported into the system via these input fields and endangering security.
But even with extensive tests and clear specifications, errors cannot be fully ruled out. Therefore, we carry out regular penetration tests in order to be able to detect and eliminate security gaps at an early stage.
All the required IT components (servers, databases) are located in specially secured areas within D-Trust. Only Bdrive administrators can access these premises according to the four-eyes principle, i.e. two administrators must authenticate themselves at the secured doors using personalized chip cards and a PIN in order to gain access. Every access is logged in an auditable form and regularly analysed by the Bdrive security team.
The premises (doors and windows) are fitted with alarm systems so that break-ins are detected at all times and reported to the responsible security team.
In addition to the use of cryptographic algorithms to secure the data, other technical, organizational and personnel measures must also be implemented to ensure secure operation of Bdrive. The necessary security measures are not only developed and implemented by our competent staff with the support of renowned research institutions but are also evaluated externally to guarantee completeness and effectiveness (see section 7).
The necessary security measures to be implemented are developed on the basis of established procedure models. Besides the implementation of the latest security measures, these also include activities for maintaining ongoing operations (e.g. emergency management, procedures in the event of security incidents and adjustments to the measures with regard to the current security situation).
Our security team is made up of one information security officer and several security experts. In addition to developing personnel, organizational, technical and infrastructural security measures, the security team's tasks also include implementing these measures and maintaining them during ongoing operations. This requires not only regular training of all employees but also adjustments to the current security situation and responding to any security incidents that may occur.
The security of Bdrive is constantly being improved. We are supported by renowned research institutions such as the Hasso Plattner Institute of the University of Potsdam and the ID Management Group of Freie Universität Berlin.
Before being hired, all employees are thoroughly vetted to ensure that they are qualified for the tasks which they are to assume. We check their training and previous employment on the basis of training certificates and job references. Employees who are to be deployed to highly sensitive areas must also present a police clearance certificate.
Bundesdruckerei regularly conducts security training courses to raise awareness for IT security and data protection. Training is not only mandatory for technical staff (e.g. system administrators and developers) but also for administrative staff and is adapted to the respective target groups. The training courses cover all relevant topics of IT security and data protection, current threats, attackers' actions (including social engineering), consequences of successful attacks and methods to minimize risks.
We also invite renowned researchers to our annual Campus Week to present the latest topics from their work and to discuss their results with us. This gives us an insight into innovative technologies so that we can continuously improve our own solution.
Software can have errors and some of these errors can also lead to security vulnerabilities. The same applies to all aspects of security implemented: ranging from personnel and organizational to technical and infrastructural.. Despite the thorough evaluation of these measures, security gaps which were not recognized during the evaluation may later be discovered.
Therefore, our security team regularly assesses the effectiveness of the implemented measures, including by simulating our own attacks such as hacking and phishing. If any gaps in security become apparent, either through our own observations or from actual attacks, we are prepared to deal with them. Our security team has already run through possible attack scenarios and has prepared appropriate countermeasures. These can range from short-term shutdown of security-critical services to shutting down Bdrive until security is restored.
We also regularly monitor the current security situation and collect information, (for example, from the Computer Emergency Response Team of the German Federal Office for Information Security) about current security gaps and attacks so that we can immediately initiate appropriate countermeasures.
All components of the Bdrive infrastructure have been evaluated and certified according to established process models. In addition to checking whether appropriate security measures have been implemented for all security risks, we also examine how effective these measures are (i.e. whether they suitably minimize risks). This evaluation looks at both the current status of implementation and at whether it is possible to respond appropriately to security incidents or current developments in attacks.
The Bdrive client is software that is needed to use Bdrive. This software implements essential security functions, such as key generation, encryption and decryption, file authentication, etc. For this purpose, we are aiming for certification according to Common Criteria EAL 4. EAL stands for Evaluation Assurance Level, i.e. the level of confidence that a solution meets certain security assurance requirements. . EAL 4 means that the app is methodically developed, tested and reviewed and therefore fulfills the claimed security functionality with a high degree of probability.
Bundesdruckerei is aiming for certification according to SEAL-3 (Security Assurance Level 3) for the entire Bdrive system. Certification is planned to be completed by the end of 2018 and will then be repeated regularly for new releases.
This certification is carried out by TÜV Informationstechnik GmbH.
The certificates used in Bdrive are the security anchor for secure data exchange. All certificates are issued by certification service provider D-Trust, a wholly owned subsidiary of Bundesdruckerei which has been an established provider in this field for many years. D-Trust issues advanced and qualified certificates in accordance with the German Act on Digital Signature. For this purpose, the security of all the processes for issuing certificates is evaluated and the evaluation is confirmed by the Federal Network Agency on the basis of a BSI certificate.
Bdrive works exclusively with independent and ISO-certified cloud storage providers whose data centers are operated in Germany. This means that the data – or even better, the encrypted and authenticated data fragments – remain exclusively in German servers.
Bdrive is being continuously further developed and tested for security. In this context, we are supported by two renowned research institutions, the ID Management Group at the Freie Universität of Berlin under the direction of Prof. Dr. Margraf and the Hasso Plattner Institute of the University of Potsdam under the direction of Prof. Dr. Meinel.
The ID Management Group at the Freie Universität of Berlin works on the design, creation and evaluation of usable and secure software and IT systems. The main research topics of the working group are: physical unclonable functions, cryptanalysis, usable security, IT security management, security management as a service.
The Hasso Plattner Institute (HPI) is unique in the German university landscape: It offers a unique practice and innovation-based program in IT Systems Engineering that ends with a Bachelor or Master of Science. It also offers a course in the Design Thinking innovation methodology. Organized as an independent Digital Engineering Faculty of the University of Potsdam, HPI combines excellent research and teaching with the advantages of a privately financed institute which is tuition-free.
AES: Symmetric encryption algorithm used in Bdrive to encrypt files and metadata
Authentication certificate: Certificate issued by a CA that is linked to an asymmetric key pair for authentication
Bdrive cloud: The infrastructure used by Bdrive for the secure storage of files and metadata
Bdrive client: Software that a company administrator or a Bdrive user installs on a device in order to use this as a client-side interface to the Bdrive service.
Bdrive customer: Company that has entered into an agreement to use the Bdrive service
Bdrive user: Employee of a Bdrive customer who uses the Bdrive service and has registered with the service for this purpose
Certification Authority (CA): Trusted body that issues certificates that can be used to check the link between cryptographic keys and key owner
Droppads: A channel for Bdrive customers to securely receive encrypted files from external partners who are not registered with Bdrive.
GoID Card: Proof of identity issued by Bundesdruckerei for employees of a company that allows the card holder to be identified with certainty
Linkshares: A channel for Bdrive customers to securely send encrypted files to external partners who are not registered with Bdrive.
MAC/HMAC: Method for authenticating data
The German ID card: Proof of identity for German citizens which allows the holder to be identified more securely and which can be used for online services (use of the online ID function)
RSA: Asymmetric encryption method with which symmetric encryption keys and authentication keys are encrypted in Bdrive
Transport Layer Security (TLS): Hybrid encryption protocol for secure data transmission on the internet
Encryption certificate: Certificate issued by a CA and linked to an asymmetric key pair for encrypting data
Certificate: A digital data record that confirms certain features of a person or object and whose authenticity and integrity can be verified using cryptographic methods.
2 BSI: IT Baseline Protection catalogues, Federal Office for Information Security.
3 BSI: TR 02102-1, Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Version 2016-01, 15. February 2016, Federal Office for Information Security.
4 BSI: TR 02102-2, Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Teil 2 - Verwendung von Transport Layer Security (TLS), Version 2016-01, Federal Office for Information Security.
5 D. Hardt: The OAuth 2.0 Authorization Framework, Internet Engineering Task Force (IETF), Request for Comments (RFC): 6749
6 B. Kaliski: PKCS#5: Password-Based Cryptography Specification Version 2.0, Request for Comments (RFC): 2898.
7 NIST: Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Special Publication 800-90A, National Institute of Standards and Technology, Technology Administration, U.S. Department of Commerce, 01/2012
8 FIPS: Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-4, 2013.