Final Report Project 374: Security Investigation of Selected Blockchain Applications

Final report project 374
Security investigation of selected blockchain applications

Federal Office for Information Security PO Box 20 03 63 53133 Bonn
Tel .: +49 22899 9582-0 E-Mail:

blockchain@bsi.bund.de Internet:
https://www.bsi.bund.de
© Federal Office for Information Security 2019
content
content
Introduction ................................................. .................................................. .................................................. ................................................. 5
Brief summary of the study results ............................................... .................................................. .......................... 6
1 Introduction to DLT using the example of blockchain ............................................ .................................................. ............................ 7
1.1 Traceability ................................................. .................................................. .................................................. ........ 7
1.2 Deniability ................................................. .................................................. .................................................. .................. 7
1.3 Consistency ................................................. .................................................. .................................................. ........................... 7
1.4 Uniqueness ................................................. .................................................. .................................................. ...................... 8th
1.5 Balance ................................................. .................................................. .................................................. .............. 8th
2nd Characteristics and assessment criteria taken into account .............................................. .................................................. ..... 9
2.1 Characteristics ................................................. .................................................. .................................................. ............................. 9
2.2 Rating ................................................. .................................................. .................................................. ........................ 12
2.2.1 Market relevance and awareness ............................................... .................................................. ............................ 12
2.2.2 Maturity level ................................................. .................................................. .................................................. ...................... 13
2.2.3 Security mechanisms / software quality ............................................... .................................................. ..... 13
2.2.4 Evaluability ................................................. .................................................. .................................................. .......... 14
2.2.5 Cryptographic mechanisms ................................................ .................................................. .......................... 14
2.2.6 Performance / scalability ............................................... .................................................. ................................... 15
2.2.7 Ease of use ................................................. .................................................. ................................................ 15
2.2.8 Security incidents ................................................. .................................................. .................................................. ... 16
2.2.9 Licensing ................................................. .................................................. .................................................. ............... 16
2.2.10 Formal proof of safety ................................................ .................................................. ........................ 17
3rd Evaluation of results ............................................... .................................................. .................................................. .. 18
3.1 Types of offers ............................................... .................................................. .................................................. ..... 18
3.2 Origin ................................................. .................................................. .................................................. ............................ 19
3.3 Licensing ................................................. .................................................. .................................................. .................... 23
3.4 Market relevance ................................................. .................................................. .................................................. ................. 25
3.5 Maturity level ................................................. .................................................. .................................................. ........................... 27
3.6 Performance ................................................. .................................................. .................................................. .................... 30
3.7 Safety ................................................. .................................................. .................................................. .......................... 31
4th Conclusions ................................................. .................................................. .................................................. ................. 35
5 Selection of the products to be examined ............................................. .................................................. ........................ 37
6 General investigation methodology ................................................ .................................................. .................................... 40
6.1 Review of the technical concept .............................................. .................................................. .............................. 40
6.2 Setting up a test environment ............................................... .................................................. ............................... 40
6.3 Static Code Analysis / Static Application Security Testing (SAST) ........................................ ................... 41
6.4 Dependency Analysis / Software Composition Analysis (SCA) ........................................ ....................... 41
Federal Office for Security in Information Technology 3rd

content
6.5 Manual review of the source text .............................................. .................................................. .............................. 41
6.6 Reverse engineering ................................................ .................................................. .................................................. ..... 42
6.7 Dynamic Application Security Testing (DAST) ........................................... .................................................. ......... 43
6.7.1 Fuzzing ................................................. .................................................. .................................................. .......................... 43
6.7.2 Error detection ................................................. .................................................. .................................................. ...... 43
6.8 Network traffic analysis ............................................... .................................................. .................................. 44
7 Basic observations and typical weaknesses ............................................. ............................................. 45
8th Conclusions ................................................. .................................................. .................................................. ................. 47
4th Federal Office for Security in Information Technology

introduction
introduction
Since the publication of the Bitcoin white paper 1 In 2008, blockchain technology, as well as offers and products based on it, was an
important topic in the discourse of business, politics and society. In response to this trend, the BSI published the position paper "Make
blockchain secure" in 2018 2nd and the federal government started preparing to create a federal blockchain strategy 3rd
Since the security and safe use of this new technology is a key factor that determines future success, the BSI decided to have a
study carried out on the security of the blockchain ecosystem.
As part of this study, the security status of current blockchain offerings should be examined in detail. This goal should be achieved in two main work packages. First, a comprehensive
overview of existing blockchain technologies should be created as part of a market analysis (at least 300). The technologies identified should already be subjected to an initial
assessment, which includes in particular the first impression of the security mechanisms used, the software quality and the security incidents that have become known so far. Then,
based on the results of the preliminary assessment, a fixed number of blockchain offers (but at least five) are selected and then subjected to a comprehensive and detailed security
analysis (this work package is hereinafter referred to as "AP5"). Different types of offers, areas of application and mechanisms should be covered, and an appropriate combination of
theoretical and practical methods should be used. Practical methods include code analysis, measurements, active and passive side channel attacks, fuzzing and penetration testing.
The investigation included as potential weak points both program errors and random number generation, side channels, cryptographic weaknesses and other aspects to be determined
by the BSI. Different types of offers, areas of application and mechanisms should be covered, and an appropriate combination of theoretical and practical methods should be used.
Practical methods include code analysis, measurements, active and passive side channel attacks, fuzzing and penetration testing. The investigation included as potential weak points
both program errors and random number generation, side channels, cryptographic weaknesses and other aspects to be determined by the BSI. Different types of offers, areas of
application and mechanisms should be covered, and an appropriate combination of theoretical and practical methods should be used. Practical methods include code analysis,
measurements, active and passive side channel attacks, fuzzing and penetration testing. The investigation included as potential weak points both program errors and random number
generation, side channels, cryptographic weaknesses and other aspects to be determined by the BSI. active and passive side channel attacks, fuzzing and penetration testing. The
investigation included as potential weak points both program errors and random number generation, side channels, cryptographic weaknesses and other aspects to be determined by
the BSI. active and passive side channel attacks, fuzzing and penetration testing. The investigation included as potential weak points both program errors and random number generation, side channels, cr
As a result of this study, a comprehensive IT security situation for blockchain applications should emerge, which is supported by
a well-founded test methodology.
1 https://bitcoin.org/bitcoin.pdf
2nd This has meanwhile been expanded into a comprehensive guide, see
www.bsi.bund.de/Blockchain
3rd This strategy is now available and can be accessed at www.bmwi.bund.de.
Federal Office for Security in Information Technology 5

Brief summary of the study results
Brief summary of the study results

The following key results and conclusions were obtained in the course of this study:
• Over 25% of all offerings from the blockchain ecosystem come from the United States. Only 9 of the 303 offers identified in
the market analysis come from Germany (see section 19).
• Mining software is mostly developed by private individuals (71%, see section

19).
• A significant part of the available mining hardware comes from China (50%, see section 19).
• Blockchain clients and hardware wallets have the highest average maturity, while blockchain applications are the least developed
(see section 3.5).
• Almost no offers can provide formal proof of security (see section 31).
• Most of the eight blockchain offerings examined in detail have a high level of security and no serious weaknesses were found within
the scope of the available investigation effort for this study.
• However, a detailed study is fundamentally insecure, another is susceptible to phishing attacks.
• All problems found were reported to the respective manufacturers. Responses to reporting less critical vulnerabilities were mostly
positive. There was no response to each of the two critical problems reported. To the best of our knowledge, none of the problems
reported in these cases have been resolved.
• Fundamental problems that were uncovered in this study are the high degree of shared code blocks between the examined
offerings (especially regarding cryptographic methods), the unusual choice of cryptographic primitives and the high number of
dependencies on external program libraries are used in outdated versions (some with known security holes) (see section 7).
In order to gain a deeper understanding of the security properties of existing blockchain offerings, building on this study, the study of the
so-called "Bitcoin Improvement Proposals" (a de facto standard in the blockchain ecosystem) and their implementations is particularly
useful.

1 Introduction to DLT using the example of blockchain
Blockchain technology first became known about the cryptographic currency "Bitcoin". When one talks about security mechanisms and
security guarantees of the blockchain, one usually means the blockchain as used by Bitcoin. The following are the key design goals of
Bitcoin and it is explained which mechanisms of the blockchain together with which assumptions achieve these goals. The blockchain
network consists of a number of independent participants who communicate with one another via “broadcasts”. The key design features
of blockchain technology are the absence of central instances, a consensus mechanism and the immutability of the blockchain. The main
goals of the Bitcoin blockchain are outlined below.
1.1 Traceability
Traceability is achieved in Bitcoin by organizing all payment transactions as a transaction of a certain amount between a sender and a
recipient. These transactions are first summarized in blocks and then transmitted to all participants in the payment system. Each
participant stores these blocks locally in a constantly growing list. Since every participant has the complete transaction list, the
correctness of each individual transaction can be traced.
1.2 Deniability
While it is impossible to spend the (cash) money of a stranger in conventional currencies, in a system in which payments are only
represented as an electronic transaction, it is quite conceivable that transactions are written in a strange name. Bitcoin solves this
problem in that all transactions are cryptographically signed by the sender. Participants are identified by an address derived from their
public key. Assuming that no attacker can forge signatures, participants can only have money that they themselves received in the form
of transactions.
1.3 consistency
In conventional payment systems, banks, as central institutions, authorize transactions and ensure that an account holder can only spend
the money he has. In a decentralized system, participants can spend money twice ("double spending") if transactions are not checked. In
order to authorize transactions, a (any) participant checks them for correctness and combines several transactions in one block. In
addition, a confirmed block always contains clear information about which block was the previous block - that is, on the basis of which
"account balance" of all participants, the transactions contained in the block were confirmed. In order to be able to enter such a block in
the blockchain, the participant must also apply a significant amount of computing power and attach the proof of this - the proof of work -
to the block. The proof of work requires two things. On the one hand, creating blocks is tied to the investment of computing time:
authorizing transactions costs electricity. On the other hand, the proof of work "slows down" the creation of new blocks: no participant can
create new blocks as quickly as desired. Only when an attacker - or a group of several attackers - controls approximately half of the total
computing power of the network can he freely dictate which transactions are validated and which are not. If a transaction has been
immortalized in the blockchain for a certain amount of time, it is almost impossible

1.4 Uniqueness
Since it is in principle possible for every participant to create a new block and it is up to him which transactions he takes into account, it
can happen at any time that different blocks are published with the same previous block - the block chain thus gets a new strand. In
order to prevent the state of the blockchain from diverging in this way, the simple rule applies that new blocks must always be attached
to the longest strand of the blockchain. If more than 50% of all participants adhere to this principle, it is not possible for an attacker to
create a new (malicious) thread in the blockchain that is recognized by other participants.
1.5 Balance
The system described so far offers no incentive for participants to participate in the verification of blocks. The proof of work requires the
investment of computing time, which is not worth it if you do not want to have a self-made transaction confirmed. To solve this problem,
participants receive a reward in the form of newly created ("mined" or "mined") bitcoins after confirmation of a block. In addition, the
sender is also able to award a reward for confirming his transaction.

2nd Characteristics and assessment criteria taken into account
2nd Characteristics taken into account and

Evaluation criteria
2.1 characteristics
There is an almost unmanageable variety of different offers in the blockchain ecosystem 4th The 303 offers that were considered
in the market analysis were therefore initially categorized according to their type. The following classes were taken into
account:
Basic technology We understand a basic technology as a blockchain technology, its

The aim and purpose is to use it as a platform or framework for the creation of further applications based
on the technology. The processing of payment transactions is not intended in particular in the technology
concept. A prominent example of this is "Hyperledger", a blockchain solution that is intended to simplify
the digitalization of corporate processes. Characteristics of basic technologies often differ in terms of their
consensus procedures and their rights management, but almost always offer a form of "smart contracts"
that can be used to implement further applications based on the blockchain.
Digital currency By a digital currency we mean blockchain technology, its

The aim and purpose is solely to process and document digital payments. In contrast to a basic
technology, a digital currency itself does not offer any mechanisms for realizing further applications, but
is aimed at the administration of so-called "coins", which can be understood like a digital image of a
coin. The most prominent example of a digital currency is "Bitcoin", which was originally developed
explicitly for realizing digital payments. Even though there are some applications that use the Bitcoin
blockchain as secure data storage, use in this form is not officially intended. In particular, Bitcoin itself
does not offer sufficiently expressive smart contracts that are suitable to implement further applications.
However, it is not always possible to clearly separate blockchain offerings in basic technologies and
digital currencies. For example, “Ethereum” is designed both as a digital currency and - via the
mechanism of smart contracts - as a basic technology for realizing further applications. Cases in which
no clear differentiation is possible were marked accordingly in the evaluation.
Blockchain We understand a blockchai application to be offers that offer an additional service based on a basic
application technology (or, if applicable, a digital currency). Blockchain applications are usually implemented as a
smart contract, but can also use an existing blockchain as a data store or interact with it in another form.
Well-known examples of blockchain applications are the so-called "dApps" - applications that are
developed on the basis of the Ethereum blockchain. Services offered by blockchain applications are often
over
4th For the purposes of this study, we mean all products and technologies that are associated with the
Blockchain ecosystem related. In the following we use the terms "offer", "product" and "technology" synonymously.

so-called "tokens" paid. Tokens are usually a form of digital currency realized via a smart contract,
which - regardless of the underlying technology - can be used for a single application. As a rule, tokens
are traded for real money, just like the “coins” of a digital currency.
Blockchain client Any software that is suitable for actively participating in a blockchain network (as a so-called “full node”)
falls into this category. This means that the client must also be able to verify transactions and “mine”
themselves. A well-known example of this is "Bitcoin Core", the official client for participating in the
Bitcoin blockchain.
Mining software In contrast to blockchain clients, mining software is only suitable for mining one or more blockchain
technologies. In particular, mining software generally does not offer any functions for carrying out
transactions.
Mining hardware Mining hardware is specialized hardware that is specifically designed to

Mining in one (or sometimes several) blockchain networks.
Blockchain wallet All hardware-based products fall into this category, the purpose of which is to securely store the key
(Hardware) material required to participate in a blockchain. Usually, a single blockchain wallet supports the storage of
key material for several different digital currencies or basic technologies. A well-known example is
"Trezor".
Blockchain wallet Key material is not only stored using secure hardware, but often also in software. Unlike hardware
(Software) wallets, software-based solutions often offer additional functionality that goes beyond mere storage,
such as triggering transactions.
Wallet generators Although almost all blockchain clients and many software-based blockchain
Wallets are already able to generate the key material for generating the wallet themselves, there is still
another class of offers that is exclusively dedicated to the generation of wallets. Most of the time, these
are web applications in which users can generate new wallets at the push of a button. As a rule, wallet
generators offer no further functionality.
Most classes of offers are only suitable for a certain application - for example for storing wallets. Blockchain applications (but also basic
technologies and digital currencies in certain cases) exist for a wide range of uses, from the implementation of a digital land register to
the recording of all stations in the supply chain of a product to the handling of transactions in local energy markets. The selection of the
fields of application considered in this study was based on the fields of application that were presented in the Federal Government's
consultation paper as part of the blockchain strategy 5.
The following adjustments have been made:
• Summary of Internet of Things (IoT) and Industry 4.0: In our opinion, the two use cases cannot be defined separately, since the
Internet of Things is one of the foundations of Industry 4.0. Applications that are designed for use in the IoT
5 The final version of the blockchain strategy is only after the essential parts of it have been implemented
Study appeared. There is no longer an explicit listing of potential fields of application. Instead, the strategy focuses on concrete implementation
projects in the areas of administration, health, digital identities, logistics and education.

thus often apply to Industry 4.0. Conversely, applications for use in the context of Industry 4.0 are often based on the Internet of
Things.
• Expansion of logistics to "supply chain management": In our opinion, the term logistics is too narrow. Applications that deal with
comprehensible supply chains, for example, would traditionally not be assigned to the term logistics. In the blockchain context,
however, these are common use cases. As part of this study, we are therefore expanding the application field of logistics to
supply chain management. This term includes offers in the context of supply chains as well as in the area of logistics.
• Introduction of the additional field of application "game": In the course of the market analysis it turned out that there are
numerous blockchain-based games that have not yet been assigned to the fields of application proposed in the consultation
paper.
Overall, applications, basic technologies and digital currencies (if possible) have therefore been assigned to the following fields of
application:
• Financial sector
• Rights management
• administration
• IoT / Industry 4.0
• Supply chain management
• Identity management
• energy
• Data storage
• health
• game
• Platform economy
• mobility
All applications, basic technologies and digital currencies that could not be assigned to any of the application fields shown
were summarized under the category "Other".
In addition to the product features mentioned above, the following questions were answered for basic technologies, digital currencies
and blockchain applications (if possible and useful):
• Authorization model: Who can view and save information in the blockchain?
• Degree of decentralization: Is the blockchain completely decentralized or does it need certain additional anchors of trust?
• Consensus model: Which procedure to ensure consensus is used in the distributed network?
• Smart contracts: Does the blockchain allow the use of smart contracts and if so in what form?
• Saved information: What class of information is the product intended for?

For all types of offers, the origin of the offer determined. For products that are manufactured and sold by a company, the country of the
company headquarters was determined. In all other cases, it was determined (for example based on the code contributions on developer
platforms) whether the product was developed by up to three private individuals or by a community (four or more people).
2.2 rating
After determining the characteristics shown in section 9, an initial assessment was made for all offers based on publicly available
information. The evaluation criteria set out below were taken into account. If no information could be found for a criterion or the criterion
was not applicable to the product, the symbol "-" was entered.
2.2.1 Market relevance and awareness
In this category, a scale of 1 to 5 was used to assess how strongly the offer under consideration is represented on the market (the
blockchain offerings). Lenses Ratings in this category were made for digital currencies, basic technologies and blockchain applications,
as well as mining software. Basic technologies and digital currencies are usually based on coins that are traded on the market and
whose value can therefore be determined objectively and is a strong indicator of the market relevance of the offer. Functionalities
provided by blockchain applications can usually be used via tokens. Just like coins, tokens are also traded on the market and therefore
serve as a suitable evaluation measure for the market relevance of the underlying blockchain application. In total, the following
evaluation scale was applied:
Benchmark: Market relevance and awareness
Rated types of offers: basic technologies, digital currencies and blockchain

Applications
rating criteria
1 The market share of the coin / token is less than 0.2%.
2nd The market share of the coin / token is 0.2-0.9%.
3rd The market share of the coin / token is 1-9%.
4th The market share of the coin / token is 10-30%.
5 The market share of the coin / token is more than 30%.
The valuation was made in January and on the total market capitalization of
$ 121,275,489,930 paid as of January 17, 2019.
Mining software is typically used for a specific mining pool. The calculation speed of the associated mining pool is therefore a
suitable indicator for the market relevance of the mining software. The following evaluation scale was therefore used:
Benchmark: Market relevance and awareness
Rated types of offers: mining software
rating criteria
1 The mining software serves a mining pool for one or more mining algorithms with a hash rate of less than 106
hashes per second.
12 Federal Office for Security in Information Technology

2nd The mining software serves a mining pool for one or more mining algorithms with a hash rate in the range of 10 6 Hashes
per second.
3rd The mining software serves a mining pool for one or more mining algorithms with a hash rate in the range of 10 9 Hashes
per second.
4th The mining software serves a mining pool for one or more mining algorithms with a hash rate in the range of 10 12 Hashes
per second.
5 The mining software serves a mining pool for one or more mining algorithms with a hash rate in the range of 10 15 Hashes
per second.
For all other types of offers, it was not possible within the scope of the workload of this study to arrive at an objective assessment of the
market relevance, because the number of users is often not published and cannot be reliably determined in any other way. In these
cases, a
subjective Evaluation (also from 1 to 5) based on the following criteria:
• Number of Google search results
• Number of downloads in the Google Play Store
• Number of discussions in relevant forums
• Information in secondary literature
2.2.2 Maturity level
The maturity of blockchain offerings was also rated on a scale from 1 to 5 according to the following criteria:
Rating scale: Maturity level Rated types of
offers: all
rating criteria
1 Only a white paper or website is available for the offer.
2nd The offer is at an early stage: there is an early prototype of the product or parts of it.
3rd The offer is in the test phase, which is not yet intended for productive use ("beta phase").
4th The offer is fresh on the market and Messages on development platforms (e.g. at Github) are observed.
5 The offer is mature and is used productively and there is a documented one. Vulnerability reporting process and
Messages on development platforms (e.g. Github) are answered and processed quickly.
Since the focus of this study is particularly on the security properties of blockchain offers, the existence of a documented process for
reporting security gaps is a necessary criterion from the FZI's point of view in order to achieve the highest level of maturity.
2.2.3 Security mechanisms / software quality
The security mechanisms used and the software quality could only be assessed superficially within the limited scope of the market
analysis. Therefore, the offers were only evaluated in two categories according to the following evaluation scheme:

Assessment standard: security mechanisms / software quality
Rated types of offers: all
rating criteria
0 The mechanisms used or the quality of the software are apparently inadequate.
1 The software architecture is obviously well thought out and the security mechanisms used seem well
suited for the application.
In particular, the following criteria were taken into account when dividing the offers into the two categories:
• There are test cases
• There are comments about the code
• Documentation exists
• The code is organized
• The security mechanisms described appear plausible for the application
• Subjective assessment of code quality
2.2.4 Evaluability
In particular with regard to the detailed analysis of selected technologies, all offers were evaluated with regard to their
evaluability on a scale from 1 to 3 according to the following scheme:
Evaluation scale: evaluability Types of offers
evaluated: all
rating criteria
1 The technology to be examined is hardly documented or the evaluation requires side channel attacks or other
attacks at the hardware level to be carried out
or the evaluation effort is exceptionally high for other reasons.
2nd The technology to be examined is poorly documented and the evaluation only requires the analysis of software.
3rd Documentation is available on the technology to be investigated, important parts of the source code are public.
Category 1 also includes in particular all offers for which only a white paper exists at the time of the market overview (between
November 2018 and February 2019) or for which it is not clear how the advertised product can be acquired.
2.2.5 Cryptographic mechanisms
In contrast to the evaluation criterion "security mechanisms / software quality", only the cryptographic measures used were
evaluated for this criterion. However, since errors are often made when implementing such mechanisms, this can only be done after
intensive analysis

noticeable, only a superficial division into two categories was made here, according to the following table:
Evaluation scale: cryptographic mechanisms
rating criteria
0 The cryptographic mechanisms used are apparently not suitable for the intended purpose or are being
used incorrectly (e.g. using the Electronic Code Book (ECB) operating mode or obviously using the wrong
key length).
1 Cryptographic mechanisms are used that appear to correspond to the state of the art.
2.2.6 Performance / scalability
The market analysis also assessed the performance of basic technologies, digital currencies and, if appropriate, blockchain
applications. Since the transaction speed is particularly relevant for most applications, this criterion was used as an approximation
for the overall performance according to the following table.
Benchmark: performance / scalability

Applications
rating criteria
1 The number of possible transactions per second is very small (reference: Bitcoin ~ 10 transactions / second).
2nd The number of possible transactions per second is small (reference: Ethereum ~ 20 transactions / second).
3rd The number of possible transactions per second is medium (reference: DASH 1,500 transactions / second).
4th The number of possible transactions per second is high (reference: Hyperledger
3,500 transactions / second).
5 The number of possible transactions per second is very high (reference: VISA 24,000 transactions / second).
2.2.7 Ease of use
For the evaluation of user-friendliness, consideration was given to the extent to which the users of an offer are provided with sufficient
documentation and assistance for setting up and using them and whether the offer was designed for use by "inexperienced" users.
The classification was based on the following table:
Evaluation scale: user-friendliness
rating criteria

1 There is hardly any documentation available on how to use the offer or the set-up is extraordinarily complex.
2nd Use of the offering requires expert knowledge, but documentation is available to help you acquire the necessary
knowledge.
3rd Detailed documentation on the use of the offer is available or created and published by users, the offer is
available for multiple platforms, and it is easy to set up.
2.2.8 Security incidents
By analyzing past security incidents, conclusions can be drawn about the general security of products. It’s less relevant if There have
been security incidents in the past (there are always security gaps in the most carefully developed products), rather than how they were
dealt with and whether the gaps themselves suggest that standard IT security practices have already been insufficiently implemented. All
offers were therefore divided into four categories according to the following table:
Evaluation scale: security incidents
rating criteria
1 In the past, security incidents have become known that suggest serious neglect of standard IT security practices.
The vulnerabilities were not corrected or only very slowly.
2nd Security incidents have been reported in the past that suggest that standard IT security practices have been
neglected. However, the vulnerabilities were remedied immediately.
3rd In the past, only security incidents were known that did not pose any danger to the system or the users. The
handling of the security incidents was exemplary.
- No incidents are known 6. An evaluation is not possible.
2.2.9 Licensing
For all offers, it was recorded whether the source text of the product (or the firmware, if it is hardware) is publicly available and, if so,
under which license it is. The evaluation was carried out on the basis of the following classification:
Rating scale: Licensing Rated types of
offers: all
rating criteria
1 The offer is proprietary and the source code cannot be viewed by any third party.
2nd The offer is proprietary, but regularly undergoes security audits by third parties or
the offer is proprietary, but the code is still public.
6 It is important to point out that no conclusions can be drawn as to the safety of the
Allow product to be derived. Just because no security incidents have become known so far, a product is not necessarily safe.

3rd The offer is licensed under a license with a strict copy-left effect: GPLv3, GPLv2, Affero GPL, Creative Commons
BY-SA.
4th The offer is licensed under a license with few usage restrictions: Apache, LGPL, MPL.
5 The offer is licensed under a fully liberal license: MIT, BSD, ISC, Public Domain.
2.2.10 Formal proof of security
In modern cryptography, formal security certificates are very important. Nowadays it goes without saying that all professionally used
public key
Encryption methods in a suitable model have been proven to be secure. Even with more complex protocols, formal security certificates
are becoming more and more popular. Since basic technologies and digital currencies generally combine different mechanisms to create
new types of protocols in order to achieve strong security properties (for example the "immutability"), a formal security certificate would
also be desirable here. In parallel to the formal security models of cryptography, formal verification has prevailed for software
applications. In this category, it was therefore additionally determined whether a formal verification was carried out or not.
The offers were classified as follows:
Assessment benchmark: formal safety evidence

Applications
rating criteria
0 There is no formal evidence of security for the security guarantee of the technology.
1 Formal safety evidence exists in a scientific publication or in a white paper.
Federal Office for Security in Information Technology 17th

3rd evaluation of results

As part of this study 303 different offers related to blockchain examined. Almost all relevant offers were taken into account for each offer
type. For digital currencies, basic technologies and blockchain applications, for example, all products up to 40th place in the market
capitalization were taken into account in accordance with "CoinMarketCap", which corresponds to 91% coverage of the entire market.
The offers considered here therefore provide a representative overview of the market.
The results developed as part of the market analysis and evaluation are available in the form of a CSV file, which is suitable for the
preparation of further evaluations. The file contains all the numerical evaluations listed in section 9 as well as free text entries, which
explain the evaluation bases in more detail in various cases.
In the following sections we present selected evaluations of the data obtained, which in our view contain the most interesting and
informative results.
3.1 Kinds of offers
Figure 1 shows the classification of the examined offers according to their type. It is striking that blockchain applications make up
almost 35% of the entire market.
Figure 1: Type of offers examined. Under "Other", various offers are summarized, the type of which cannot be clearly determined (for example, because
they are intended both as an application and as a digital currency) and which together make up less than 1.7% of the entire market.
Figure 2 shows which of the examined blockchain applications were developed for which field of application. If an application is suitable
for two or three fields of application, the dominant application was taken into account. For example, basically all applications can in
principle be used as data storage, even if this is not their actual application. Applications that support many different use cases have
been classified as platforms under platform economics.
The evaluation clearly shows that blockchain applications are heavily used in the financial sector as well as for games, while the use
for IoT, identity management, administration and energy is only in

to a small extent. A large part of the examined applications could not be assigned to any of the fields of application defined at the
beginning.
Figure 2: Fields of application of the examined blockchain applications, digital currencies and basic technologies. "Other" means that the product
cannot be assigned to any of the fields of application listed at the beginning.
3.2 origin
Figure 3 shows the origin of the examined offers. What is particularly striking here is that over a quarter of all blockchain offerings come
from the USA, while Germany is represented with just under 3%. In relation to the size of the population, an above-average number of
offers (12) come from Estonia. One reason for this could be the success of the country's consistent digitization strategy. It is also striking
that a significant proportion of the products are not manufactured and distributed by a company, but by private individuals or a
community. Figure 4 shows the origin of offers with market penetration 4 and 5 and Figure 5 shows the origin of examined offers with
maturity levels 4 and 5.

Figure 3: Origin of the examined products. The "Other" category summarizes all countries from which three or fewer products come.
Figure 4: Origin of the examined products with market penetration 4 and 5.

Figure 5: Origin of the examined products with maturity levels 4 and 5.
Figure 6 and 7th show the distribution of the origins of basic technologies and digital currencies as well as blockchain applications. It
is striking that the Asian region (China and Singapore) and community-developed solutions for digital currencies and basic
technologies are strongly represented, while a surprising number of blockchain applications come from Estonia. The United States is
strongly represented in both categories.
Federal Office for Security in Information Technology 21st

Figure 6: Origin of basic technologies and digital currencies.
Figure 7: Origin of blockchain applications. The "Other" category summarizes all countries from which three or fewer products come.
Figures 8 and 9 illustrate that most of the mining software is developed by private individuals, while half of the mining
hardware comes from China.
Figure 8: Origin of mining software.

Figure 9: Origin of mining hardware.
3.3 Licensing
Public source code is available for almost half of the offers examined, and almost half of them (22.5%) have even been published
under a very liberal license. Overall, the impression arises that blockchain offers tend to be developed more openly and
transparently. Only mining hardware and blockchain applications are an exception here. All mining hardware products that have been
investigated do not have any public source code and are developed completely proprietary. A similar picture emerges for blockchain
applications as for other examined categories: for a large part of the applications, the licensing cannot be determined (for example,
because it is not clear whether there is a product at all) or the code of the product is not public.

Figure 10: Licensing of the investigated products according to the criteria specified in section 2.2.9.
Figure 11: Licensing of the examined blockchain applications according to the criteria specified in section 2.2.9.

3.4 Market relevance
In terms of market relevance, it is striking that a large part of the offers (almost 50%) are almost unknown on the market. Here, too,
blockchain applications make the largest contribution: almost 70% of all applications have very little market relevance.
Categories two to four are roughly evenly distributed across all offers and show no statistical abnormalities. Figures 12
and 13 visualize these results.
Figure 12: Market relevance of all examined products. "-" means that an assessment of the relevance could not be made (for example due to
missing information).

Figure 13: Market relevance of the blockchain applications examined. "-" means that an assessment of the relevance could not be made (for
example due to missing information).
An analysis of all offers with market relevance 4 or 5 (Figure 14) with regard to their type shows that blockchain applications are strongly
underrepresented in relation to their total number - only the "Circle Pay" and "Whisper" applications fall into this category. In contrast,
wallets, mining software and blockchain clients in particular are highly relevant on the market.
Figure 14: Distribution of the examined types of offers with market relevance 4 and 5 (44 in total).

3.5 Maturity level
With regard to the level of maturity, it is particularly striking that a large part of the blockchain applications examined are at an early
stage of development. Over 50% of the applications examined have maturity level 1 or 2 (which means that there is no more than a
website and possibly a prototype implementation for the offer) and only about 7% of the offers have maturity level 5 (which means,
among other things, that it a documented process for reporting security gaps). Figure 15 shows the evaluation of the maturity level of
the blockchain applications examined.
Figure 15: Maturity level of blockchain applications according to the criteria defined in section 2.2.2.
The overall view (Figure 16) also gives the impression that the offers available on the market are not necessarily mature. Overall,
just under 40% of the offers are in maturity level 4 or 5.

Figure 16: Maturity level of all examined offers based on the criteria defined in section 2.2.2.
If you look at the distribution of the types of offers that have maturity level 1 or 2 (Figure 17), you will notice that the majority of them are
blockchain applications. Even taking into account the fact that blockchain applications make up over 30% of the total of the offers
examined, they are disproportionately represented in this evaluation with 75%.
Figure 17: Types of offers with maturity levels 1 and 2 according to the criteria shown in section 2.2.2.
However, the situation is different with hardware wallets. Here, over 40% of the products are even in maturity level 5 and over 20% of
the products in maturity level 4 (see Figure 18). So that hardware wallets are usually managed with key material for access to larger
amounts of money, it is not surprising that security is a high priority for manufacturers and customers.

Figure 18: Maturity level of hardware wallets according to the criteria described in section 2.2.2.
Figure 19 shows the average level of maturity of the examined types of offers. It can be clearly seen that blockchain applications have
the lowest level of maturity on average, while blockchain clients and hardware wallets are very mature on average.
Figure 19: Average degree of maturity of the examined products by product class according to the in section
2.2.2 Criteria presented.

3.6 performance
As is the case in other categories, the performance of blockchain applications cannot be assessed in most cases. In cases where a
reliable statement is possible, it becomes clear that only very few applications achieve high performance. Most applications are in
categories 1 and 2 (between 1 and 20 transactions per second). An assessment can be made more frequently for basic technologies
and digital currencies, but the distribution of performance is similar. Figures 20 and 21 visualize these results.
Figure 20: Performance of the examined blockchain applications according to the criteria defined in section 2.2.6.

Figure 21: Performance of the examined basic technologies and digital currencies according to the in section
2.2.6 defined criteria.
3.7 safety
For a majority of the offers examined (over 85%), no security gaps have been discovered so far (see Figure 22). However, these
statistics alone do not provide any information about safety, since it can also mean that the vast majority of products have not yet been
examined. In fact, as part of our research, we were only able to find “Hyperledger” 7 and "Augur" 8th Find a commissioned and published
comprehensive security analysis (as you would expect in a "penetration testing report", for example). In three other cases (exclusively
hardware wallets), research groups or companies that are not related to the manufacturer have carried out extensive security analyzes
and published them at least as part of a publicly available lecture.
In all other cases there may be descriptions of security holes found (on blogging platforms, private websites, sometimes also on the
websites of the manufacturers); however, these are not part of a comprehensive, published security analysis.
7 https://wiki.hyperledger.org/download/attachments/2393550/management_report_linux_foundation_fabric_a
ugust_2017_v1.1.pdf? version = 1 & modificationDate = 1548107421000 & api = v2
8th https://blog.openzeppelin.com/serpent-compiler-audit-3095d1257929/

Figure 22: Known security incidents of all examined products according to the criteria defined in section 2.2.8.
With regard to the security mechanisms and software quality, it is initially noticeable that this category cannot be assessed in over a
third of all examined offers (Figure 23). The reason for this seems to be in particular the overall low level of maturity of the blockchain
applications examined, which is also confirmed in Figure 24. It is also worth noting that only a very small part of all products (evenly
distributed across all product classes) are obviously inadequate in terms of the mechanisms used or the quality of the software.
Figure 23: Security mechanisms and software quality of all examined products according to the in section
2.2.3 defined criteria.

Figure 24: Security mechanisms and software quality of the examined blockchain applications according to the criteria defined in section 2.2.3.
If cryptographic mechanisms are used correctly, the behavior is almost identical across all types of offer (see Figure 25). Here, too,
blockchain applications represent the majority of those offers that could not be rated in this category (approx. 68%). Cryptographic
mechanisms, particularly in the case of software wallets, are often disproportionately poorly rated in a preliminary analysis, while other
types of offers are inconspicuous with regard to this feature.
Figure 25: Use of cryptographic mechanisms of all examined products according to the criteria specified in section 2.2.5.

Formal evidence of security exists for very few offers, as can be seen in Figure 26.
Figure 26: Existence of formal safety evidence for the investigated products according to the criteria specified in section 2.2.10.

4th Conclusions
4th Conclusions
Based on the analysis and evaluation we have made, the following general conclusions are reasonable:
• There are almost no offers with formal security evidence that affect significant parts of the offer.
Formal security evidence exists for the cryptographic components used, such as encryption processes or signature functions, but
many blockchain offerings promise security properties that go far beyond this, such as immutability or resistance to Sybil attacks. As
a rule, there is no formal evidence or scientific investigation for these statements. Although most offers make security the central
theme of their advertising message, there is generally no formal verification for the software components used (or for parts of them).
• Blockchain applications hardly play a role in the market.

Almost 80% of all examined applications have a small or very small market relevance. Blockchain applications also lag behind
other types of offerings in terms of maturity: only just under 20% of all applications have a high or very high degree of maturity, and
over a third of all applications have not yet reached the stage of a marketing website. With an average maturity of 2.38, blockchain
applications are the least developed type of blockchain offerings on the market. The overall impression is that there are as yet
almost no applications for blockchain technology in use.
• Existing offers have so far hardly been subjected to public security analyzes or "penetration tests".
Although the main selling point of most blockchain offerings is security, only a few individual cases have commissioned independent
security examinations and the results have been published. In some other cases, vulnerabilities have been discovered by
independent researchers. In almost all cases, these were quickly rectified. An exception to this are hardware wallets and blockchain
clients, which have been researched well above average, but together account for less than 10% of the total number of offers
examined.
• Blockchain clients and hardware wallets are the offers with the highest level of development.
A documented process for reporting security vulnerabilities exists for over 40% of the hardware wallets examined and for 50% of the
blockchain clients examined. A large number of the commercially available wallets and clients have already been subjected to a
security analysis. These figures can be explained especially against the background that security gaps in these offers can quickly
lead to the loss of a large amount of money.
• Mining hardware comes from China and mining software from private individuals.
Over 70% of the mining software examined is developed by private individuals - the main sales channel is a public forum. Half
of the commercially available mining hardware comes from China; Israel, Sweden, Japan and the USA each have only one or
two products.
• Payment transactions and games are the main areas of application for existing blockchain applications.
The majority of the examined blockchain applications (approx. 20%) are intended for use in the financial sector, the second
largest part are games that have their game data in the

4th Conclusions
Manage blockchain. In particular, the fields of administration, IoT, identity management, health and energy, which are often
mentioned as the main selling point for blockchain technology, have so far hardly been covered by existing blockchain applications.
A significant part of the applications (approx. 22%) cannot be assigned to any of the classic fields of application.

5 Selection of the products to be examined

Based on the market overview, 8 products were selected as candidates for a more in-depth investigation in consultation with the
BSI. In addition to the goal of covering as many fields of application and types of offer, the following evaluation criteria also
influenced this selection:
• Market relevance and awareness: The higher the market relevance of an offer, the higher the potential for AP5 was seen, since
security gaps in a known offer potentially affect a larger group of users. Offers that are currently of rather low market relevance, but
which can be assumed to change in the future, were also estimated to have a high potential for AP5.
• Security incidents: Known security incidents have an impact on the assessment of the potential for AP5 in different ways. On the
one hand, offers in which a large number of security analyzes have already been carried out and which accordingly also have
many known security incidents (which, however, could mostly be dealt with and solved quickly and professionally) were generally
not considered for a further investigation. With such offers, we considered it unlikely that further security gaps would be found
within the limited investigation effort of this study. In particular, those offers were taken into account for which no known security
investigations had previously been carried out or for which security analyzes already carried out suggest that
• Security mechanisms / software quality and cryptographic mechanisms: The offers, where the security mechanisms, the
software quality or the cryptographic mechanisms were obviously inadequate, tended to be taken into account for a further
investigation.
• Evaluability: When making the selection, care was taken not to select too many offers that are difficult to evaluate (for example
because there is no public source code) in order to keep the overall effort of the study within a realistic range. At the same time,
however, not only offers that are easy to evaluate should be selected so that other attack techniques (such as “reverse
engineering”) can also be demonstrated.
The criteria "formal evidence of security" and "performance" had no influence on this assessment, since, in our opinion, they do not
allow any statement about the suitability of an offer for an examination within the framework of AP5. In particular, the existence of
formal security evidence can on the one hand indicate that the provider attaches great importance to security and that further
investigation is therefore not necessary. On the other hand, for example, a formal analysis at concept level says nothing about the
actual implementation and further investigation can therefore be very interesting.
As a result, the following 8 offers were selected:
• Corda: Corda is a basic technology that was specially designed for use in a corporate context (similar to Hyperledger, for example).
Although Corda is not primarily focused on healthcare use, the technology is becoming intense for

advertised an application in the health context. Corda is already enjoying some media attention. In the absence of more suitable
alternatives, the Corda study covers the “health” application area.
• OriginTrail: OriginTrail is a blockchain application that is specifically designed for the SupplyChain Management application field.
The product is currently in a test phase and has therefore only been capitalized slightly so far. However, it is already receiving great
attention in the relevant media. It can be assumed that OriginTrail will occupy a larger part of the market in the future. It is therefore
particularly obvious to carry out a security check before the offer is used across the board.
• VeChain: Similar to Ethereum, VeChain is a mixture of basic technology and digital currency. The VeChain blockchain is intended to
store information about certain products. In contrast to OriginTrail, VeChain is significantly more capitalized and is supported by a
large number of large companies. The investigation of VeChain and OriginTrail covers the application field "Supply Chain
Management".
• Sia: Sia is a blockchain-based cloud data storage that allows users to make free space available to other users. This concept
poses significant security risks for users, since they essentially allow strangers to access their hard drives. Like OriginTrail, Sia is
currently still slightly capitalized, but is receiving a lot of media attention. It can therefore be assumed that Sia will occupy a large
part of the market in the future. Sia's investigation covers the field of data storage.
• Exodus: Exodus is a software wallet. Exodus is particularly interesting for an investigation because, according to the
manufacturer, the software comes with support for over 80 different coins and tokens and a security vulnerability accordingly has
a high potential for damage. Exodus is mentioned in some specialist media as one of the most important software wallets and is
therefore known on the market.
• Trust Wallet: Trust Wallet is a software wallet for Android and iOS. It supports a variety of different currencies and is well known. The
study of Trust Wallet and Exodus follows the assessment that software wallets pose a high risk for users. Therefore, the investigation
of a desktop application and an app is obvious.
• EOS: EOS is a basic technology that is especially intended for the implementation of decentralized applications (so-called
“dApps”). According to the manufacturer, EOS is intended as a kind of "blockchain-based operating system". EOS has a market
capitalization of over 3 billion euros. An investigation is particularly interesting against the background of this high market
relevance and due to the new concepts used, such as the specially developed consensus model.
• BitBox: Bitbox is a hardware wallet that can also be used as a second factor for authentication protocols. What is special about
Bitbox is that the secret information used to authenticate transactions can be saved on an SD card and the device does not have
a display to show transaction details. This results in special requirements for the implementation of security measures, which can
be analyzed as part of a detailed investigation. Furthermore, the manufacturer of BitBox is one of the few European
manufacturers of hardware wallets. The investigation of BitBox particularly covers the required use of analysis techniques for
hardware.
At the time the offers were selected, we were not aware of any publicly known or publicly viewable professional security analyzes. The
source code of Corda, OriginTrail, VeChain and EOS are each publicly available and an investigation is therefore relatively easy. For this

We therefore used three offers automated analysis tools such as static code analysis and fuzzing and carried out a manual check of
the security-relevant code parts (in particular with regard to the generation of random numbers and the correct use of cryptographic
primitives). The source code of Exodus and Trust Wallet is not public, so we use tools for reverse engineering and debugging here.

6 General investigation methodology

In the following, we describe a general procedure that can generally be used when examining products from the blockchain ecosystem.
Not all methods can be applied to every product; for example, static code analysis is only possible with the source code available. Most
of the time, however, it begins to develop an understanding of the product, for which a review of the technical concept is particularly
suitable.
6.1 Review of the technical concept
The technical concept is usually reviewed on the basis of the concept papers and other documentation published by the manufacturer. If
these are not available, the concept can only be assessed after extensive reverse engineering, insofar as this is possible at all.
Depending on the scope and depth of detail of the present documentation, the technical concept can only be assessed partially or only at
a higher level of abstraction. Based on the available documentation, the basic idea is first extracted and then the entire concept is tested
in several steps in order to develop an understanding of the product. On the basis of the basic idea, in particular the values to be
protected (e.g. monetary values, personal data) are identified so that their appropriate protection can be checked in the further course,
After identifying the basic idea, the concept is then examined in greater detail. The components used are examined to determine which
safety properties they have to fulfill in order to fulfill their respective tasks. It is also assessed whether this is plausible under the existing
conditions. For components developed in-house, this process may be repeated recursively until known standard components or
(cryptographic) primitives are identified for which such an assessment is possible. Since the correct use of cryptographic primitives in
particular is not trivial, it may be noted what needs special attention when examining the implementation. If the manufacturer developed
a (sub) component himself instead of using a standard solution,
After the structure of the product or the connection of the components has been worked out, it is checked whether the concept
presented is suitable for ensuring an appropriate level of protection for the previously identified protective goods.
6.2 Establishment of a test environment
In order to analyze the function of products in different operating states, a test environment must be set up in which these states can be
simulated. The type of test environment depends heavily on the product, but in general it is common to first set up the simplest possible
environment. For software products, this can be achieved, for example, by a virtual machine with a freshly installed, current operating
system without special configuration. The use of virtual machines also simplifies the reproduction of tests, since the snapshot function
allows the state of a machine to be saved and the machine to be reset to this state later. In addition, it is often necessary to set up an
individual development environment, depending on the programming language, for a product,
Depending on the behavior of the product to be analyzed, the test environment must be configured differently. For example,
analyzing network traffic may require a different environment than debugging the product. The

The test environment is therefore heavily dependent on the product, the test to be carried out and the preferences of the examiner
and cannot be described in general.
6.3 Static code analysis / static application security testing

(SAST)
For this purpose, programs are used which check the pure source text for runtime information for errors and quality before compiling. The
quality of the source code is important for application security. The reason for this is that errors can creep into confusing and
incomprehensible source text and remain unnoticed. A number of tools for such analyzes already exist for most of the common
programming languages. These tools often work by searching the source text or its abstract syntax tree and other intermediate static
formats for known error patterns. These tools often produce a large amount of information such as warnings, quality measures, and
suggestions for improvement. Due to the large flood of information and frequent "false positives", these tools alone are not suitable for a
security analysis of the program code. Nevertheless, these tools are particularly easy to set up and execute and are suitable for getting
an overall view of the quality of the code. They thus provide initial information for program paths that can be examined manually or
dynamically. This requires access to the source text.
6.4 Dependency Analysis / Software Composition Analysis (SCA)
These tools analyze the software's dependencies on third-party sources. Such dependencies are part of day-to-day business and are
used excessively, especially in the programming languages Java, Javascript and Kotlin, in order to achieve the desired functionality.
Such a modular structure makes sense from a development perspective. From a security perspective, however, a cautious approach is
recommended, as responsibilities and trust are outsourced to third parties. Integrated program libraries often contain security gaps that
endanger the security of the overall application.
The functionality of these tools is very simple. Each of the dependencies has a unique character string, the "Common Product
Enumeration" (CPE). In addition, the entire CVE database is downloaded and searched for the CPEs found. The SCA alone is also not
sufficient. A vulnerability found with SCA is no guarantee that this vulnerability can also be exploited. When integrating a dependency,
only minimal functionality is often used, through which the weak point of the program library may not be exploitable. A manual analysis of
the weak points found is therefore imperative. The benefits of SCA are therefore similar to the benefits of SAST. For SCA, access to the
source text is usually not necessary,
6.5 Manual review of the source code
If the technical concept is understood, a manual analysis of the source text is the next logical step. Such an analysis is used to assign
the components of the technical concept to the code architecture, for example to modules and packages. As an aid, the code is
examined at runtime in debug mode and the assignment confirmed. A functioning test environment is a prerequisite for this. Once the
code architecture is understood, you can start to subject parts of the source code to a security analysis. Manual analysis is only suitable
for the analysis of smaller parts of the code and does not scale for complex program structures. The following list should emphasize the
criteria according to which parts of the code can be selected for a manual review.
• Ideally, analyzes from SAST and SCA have already provided the first indications of weaknesses, so that one can initially
concentrate on the affected parts of the source text.

• In addition to the advice from SCA and SAST, cryptographic components - in particular those that implement themselves and
therefore not examined - are suitable candidates for a manual review. However, to fully investigate the implementation of a
cryptographic module for security, a broad, independent analysis is necessary that would go beyond the scope of a general
investigation of application security. Nevertheless, an examination of the conformity of the implementation with accepted standards,
eg "Request for Comments" (RFC), is a suitable means to explore the security of cryptographic implementations as part of a general
analysis of application security using the manual code review. There are also several properties which indicate an improper
implementation of cryptography. On the one hand, the use of chance, depending on the method, is a security-critical point. It is
particularly important to ensure that sufficient amounts of entropy are used for keys and random generation. If less entropy is used
than is necessary for the key length, the security guarantees of the cryptographic process no longer exist. The use of more entropy
than is necessary for the key length, on the other hand, speaks for an improper use of cryptography and a closer look could reveal
errors. The deterministic use of the ECDSA (Elliptic Curve Digital Signature Algorithm) signature process is of particular importance
in blockchain implementations. Deterministic signatures are particularly susceptible to the so-called "fault injection attacks", which
can be carried out using the "Rowhammer" method, for example. The first signs of vulnerabilities are successive signatures for
identical messages. If such signatures can even be triggered externally, caution is advised.
• API implementations are often the largest attack surface because they have to deal with potentially malicious inputs.
Examination of the validation mechanisms of such inputs gives an insight into the quality of the implementation. It is also
necessary to determine which users or systems can access the API function. However, complete code security review can only
be achieved in rare cases with manual code review. Such interfaces can be tested more precisely with the "fuzzing" method.
6.6 Reverse engineering
If an application is not available in the source text, a review of the program code is associated with more effort. Reverse engineering can
still provide some insight into the application. Depending on the programming language used, there are different tools that translate the
program code into a human-readable format. A distinction is made between disassembler and decompiler. A disassembler translates
binary code into assembly code, while a decompiler aims to reconstruct the binary code into a high-level language such as C or Java,
thereby further increasing readability. If you have the code in an assembler or high-level language, you can proceed analogously to the
review of the source text. However, the review is generally more time-consuming because comments and often speaking variable and
method names are missing in the code.
Reverse engineering may also be necessary for applications that are available in the source text. For example, proprietary software
uses code obfuscation techniques to make program code analysis more difficult. This means that the program code is changed in such
a way that it is more difficult for people to read. For example, speaking variable names are replaced by randomly generated names, or
the control flow of the program is complicated by dummy functions. Depending on the language, tools also exist here that attempt to
automatically undo the obfuscation and thereby make the program code more readable. However, the quality of such tools varies
widely. As a last resort, dynamic methods such as debugging are available to the tester. Observing the program at runtime often
provides helpful insights into how the application works, despite being obfused. However, this method is also very time-consuming and
can therefore usually only be carried out for selected parts of the program code.

6.7 Dynamic Application Security Testing (DAST)
If the source text is too complex, for example due to many branches and data types, the manual code review no longer scales. This is
often the case with larger APIs. In this case, the use of so-called "fuzzers" is recommended. These tools are designed to automatically
test as many program paths for security as possible. Depending on the fuzzer, the testing of the program paths is carried out more or
less intelligently. A program path is usually tested by processing a particular input by the application. Fuzzers generate a large amount of
input and deliver it to the specified interface in the application, while the behavior of the application is recorded in the background in order
to reconstruct errors. In summary, the main task of the fuzzer is to provoke errors in the application.
6.7.1 Fuzzing
There is a multitude of fuzzers and the selection must be carefully considered for an effective analysis of application security. A
distinction is made between two different types of fuzzing:
• Blackbox fuzzing: Here, software is examined that is only available as an executable file, for example. The source code of the
software is not available for this test. This means that the software has to be executed and then examined for all possible inputs. This
enables errors to be found due to unforeseen user input and API calls. "Dumb Fuzzer" or "Grammar Fuzzer" can be used for the
tests. The former changes an entry randomly. For example, a given username "Test123" becomes "Teet55555". If the input is not
processed correctly, an input that is too short, too long or an input with special characters can lead to an error. With a "Grammar
Fuzzer" the input is given in the form of a grammar. For example, the grammar can describe an HTML file, so that each page must
contain an "html", "head" and "body" tag in a specific order. The fuzzer generates various inputs and automatically discards all results
that do not correspond to the grammar. This ensures that only entries that are approved by the system are checked and that complex
errors can be searched for more efficiently.
• Whitebox Fuzzing: In addition to the software that is to be examined for errors, the source code of the application is also available for
Whitebox Fuzzing. This has the advantage that it can be checked in the program code which places in the program run can be
reached with a certain input. In the next step, the input can be changed so that a different branch is run through in the program
sequence. The aim is that at the end all lines in the program code are reached at least once in order to find bugs hidden deep in the
program code.
6.7.2 Error detection
In the simplest case, the application simply crashes due to an induced error, which is very easy to recognize. More complicated errors,
such as memory leaks, are more subtle and can only be discovered using additional tools. Such tools are usually already built into
compilers and can be activated in the form of flags if necessary during the compilation process. The clang compiler for C ++ is
particularly advanced with its sanitizer tools. The functionality of the sanitizer provides for the program layout to be provided with
additional control mechanisms during compilation, for example using “shadow memory”. These control mechanisms monitor, for
example, the memory layout of the application during execution and create detailed error messages when detection is successful.

6.8 Network traffic analysis
By analyzing the network traffic of a product, you can determine how well data is protected during transmission and to which systems
data is transmitted at all. To do this, a product's network traffic is routed through a test system. Traffic can be examined passively with
wireshark on the test system. Unencrypted network traffic, for example via HTTP, can be identified with little effort. If the product uses
TLS, active tests should also be carried out, since errors are always made during the certificate check. Tools like mitmproxy can be used
to test the certificate check. To identify the transferred data, the product's certificate verification can also be deactivated manually.

7 Basic observations and typical weaknesses
7 Basic observations and typical ones

weaknesses
The studies carried out as part of this project indicate two major structural problems that affect a large number of blockchain products and
technologies: the large number of dependencies on third-party program libraries and identical code blocks that are shared by a large
number of implementations .
As will be explained in the following sections, implementations in the blockchain ecosystem often use a large number of third-party program libraries, which, particularly in the case of
nodeJS, are often imported directly from a Github project. Although applications that do not come from the blockchain ecosystem are certainly also based on a large number of
program libraries, there are special challenges in the context of blockchain. In particular, basic technologies, digital currencies and blockchain applications are based on the fact that
all users agree on what the current version of the client software that is to be used to participate in the network is. Changing the client software is therefore very time-consuming and
always associated with the risk that not all users switch to the new version and there is a fork in the blockchain. This is different from, for example, Windows, where Microsoft can
theoretically force all users to install a certain security update. The dependency on a large number of program libraries therefore creates special challenges in security and patch
management in the blockchain context, which have so far been insufficiently addressed. The direct integration of program code from a Github project also harbors the risk that project
owners can inject malicious code into third-party applications without being noticed install a specific security update. The dependency on a large number of program libraries therefore
creates special challenges in security and patch management in the blockchain context, which have so far been insufficiently addressed. The direct integration of program code from a
Github project also harbors the risk that project owners can inject malicious code into third-party applications without being noticed install a specific security update. The dependency
on a large number of program libraries therefore creates special challenges in security and patch management in the blockchain context, which have so far been insufficiently
addressed. The direct integration of program code from a Github project also harbors the risk that project owners can inject malicious code into third-party applications without being
noticed
- as happened recently in the case of the Bitcoin wallet "Copay" 9.
In addition, blockchain-based products and technologies generally use cryptographic primitives to achieve certain security properties.
However, the implementation of these primitives is often based on a shared code basis. This is particularly noticeable when implementing
the "secp256k1" elliptic curve, which is used for creating and checking signatures. A large number of products use the publicly available
implementation of Bitcoin for this. Although it is generally a good recommendation not to implement cryptographic primitives yourself, but
to use sufficiently tested standard implementations, it is questionable whether the Bitcoin implementation of "secp256k1" fulfills this
requirement. Figure 27 shows the github side of the implementation and shows
Figure 27: Publicly available implementation of the "secp256k1" curve from Bitcoin's Github repository.
9 https://www.heise.de/security/meldung/NPM-Paket-EventStream-mit-Schadcode-zum-Stehlen-von-
Bitcoins-infected-4233171.html

7 Basic observations and typical weaknesses
If a safety-critical implementation error should be found in this research implementation, the question arises how to deal with it. If the fault
is reported to all affected manufacturers at the same time, there is a risk that individual manufacturers may exploit the fault in competing
products before it has been rectified. Solving this dilemma remains a challenge to be solved for a variety of blockchain products and
technologies.

8th Conclusions
8th Conclusions
In summary, it can be said that products and technologies from the blockchain ecosystem have an unusually high level of security
maturity - especially when you consider the low age of the technology field. A fundamentally different development seems to have taken
place here than with the “Internet of Things”. While very basic security measures, such as authentication or transport encryption, are
often missing or incorrectly applied to products from the Internet of Things, the developers of blockchain products do not seem to have
made the same mistake. The reasons for this can be assumed from the strong focus on IT security and the high volume of finance in the
blockchain market. Both factors make it attractive for IT security experts to work in the blockchain environment.
It is striking, however, that very few concepts and solutions from the blockchain ecosystem have been scientifically researched. This
can be seen in particular from the small number of published scientific publications that have undergone a peer review process. This is
particularly problematic because the safety guarantees given by different products are new and often not fully understood. As a rule,
they should be achieved by a combination of different cryptographic measures. If one were to follow the standard methodology known
from cryptography research, a formal security certificate would be required, which means that none of the known blockchain
technologies can currently serve.
The examination of selected products and technologies has shown that known methodologies from classic penetration testing (such as
static code analysis, fuzzing and reverse engineering) can also be used for blockchain products. However, a challenge is the high initial
effort that is already necessary to set up a test system. Since the blockchain-specific code parts (e.g. the implementation of the elliptic
curve) are identical in many products, it is questionable whether it is necessary to create your own test methodology for blockchain
products. It seems more expedient to carry out a targeted examination of the code components divided in this form, since the results will
affect a large number of products.

Final Report Project 374: Security Investigation of Selected Blockchain Applications

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Report Project 374: Security Investigation of Selected Blockchain Applications

Uploaded by

Copyright:

Available Formats

Final report project 374

Security investigation of selected blockchain applications

Tel .: +49 22899 9582-0 E-Mail:

Introduction ................................................. .................................................. .................................................. ................................................. 5

Brief summary of the study results ............................................... .................................................. .......................... 6

1 Introduction to DLT using the example of blockchain ............................................ .................................................. ............................ 7

1.1 Traceability ................................................. .................................................. .................................................. ........ 7

1.2 Deniability ................................................. .................................................. .................................................. .................. 7

1.3 Consistency ................................................. .................................................. .................................................. ........................... 7

1.4 Uniqueness ................................................. .................................................. .................................................. ...................... 8th

1.5 Balance ................................................. .................................................. .................................................. .............. 8th

2.1 Characteristics ................................................. .................................................. .................................................. ............................. 9

2.2 Rating ................................................. .................................................. .................................................. ........................ 12

2.2.1 Market relevance and awareness ............................................... .................................................. ............................ 12

2.2.2 Maturity level ................................................. .................................................. .................................................. ...................... 13

2.2.3 Security mechanisms / software quality ............................................... .................................................. ..... 13

2.2.4 Evaluability ................................................. .................................................. .................................................. .......... 14

2.2.5 Cryptographic mechanisms ................................................ .................................................. .......................... 14

2.2.6 Performance / scalability ............................................... .................................................. ................................... 15

2.2.7 Ease of use ................................................. .................................................. ................................................ 15

2.2.8 Security incidents ................................................. .................................................. .................................................. ... 16

2.2.9 Licensing ................................................. .................................................. .................................................. ............... 16

2.2.10 Formal proof of safety ................................................ .................................................. ........................ 17

3rd Evaluation of results ............................................... .................................................. .................................................. .. 18

3.1 Types of offers ............................................... .................................................. .................................................. ..... 18

3.2 Origin ................................................. .................................................. .................................................. ............................ 19

3.3 Licensing ................................................. .................................................. .................................................. .................... 23

3.4 Market relevance ................................................. .................................................. .................................................. ................. 25

3.5 Maturity level ................................................. .................................................. .................................................. ........................... 27

3.6 Performance ................................................. .................................................. .................................................. .................... 30

3.7 Safety ................................................. .................................................. .................................................. .......................... 31

4th Conclusions ................................................. .................................................. .................................................. ................. 35

5 Selection of the products to be examined ............................................. .................................................. ........................ 37

6 General investigation methodology ................................................ .................................................. .................................... 40

6.1 Review of the technical concept .............................................. .................................................. .............................. 40

6.2 Setting up a test environment ............................................... .................................................. ............................... 40

6.4 Dependency Analysis / Software Composition Analysis (SCA) ........................................ ....................... 41

Federal Office for Security in Information Technology 3rd

6.5 Manual review of the source text .............................................. .................................................. .............................. 41

6.6 Reverse engineering ................................................ .................................................. .................................................. ..... 42

6.7 Dynamic Application Security Testing (DAST) ........................................... .................................................. ......... 43

6.7.1 Fuzzing ................................................. .................................................. .................................................. .......................... 43

6.7.2 Error detection ................................................. .................................................. .................................................. ...... 43

6.8 Network traffic analysis ............................................... .................................................. .................................. 44

7 Basic observations and typical weaknesses ............................................. ............................................. 45

8th Conclusions ................................................. .................................................. .................................................. ................. 47

4th Federal Office for Security in Information Technology

Federal Office for Security in Information Technology 5

Brief summary of the study results

• Mining software is mostly developed by private individuals (71%, see section

• However, a detailed study is fundamentally insecure, another is susceptible to phishing attacks.

Federal Office for Security in Information Technology 6

1 Introduction to DLT using the example of blockchain

Federal Office for Security in Information Technology 7

8th Federal Office for Security in Information Technology

2nd Characteristics taken into account and

Basic technology We understand a basic technology as a blockchain technology, its

Digital currency By a digital currency we mean blockchain technology, its

Federal Office for Security in Information Technology 9

Mining hardware Mining hardware is specialized hardware that is specifically designed to

The following adjustments have been made:

10th Federal Office for Security in Information Technology

• IoT / Industry 4.0