The end-user perspective is quite easy. Based on available functionality, there aren't many use-cases for this actor and, in terms of functional classes, not many types of threats. In fact, there is one major use-case which is: End-user is signing the transaction and submitting it to the network.

Under the term of transaction we include the following:

• Purchasing services
• Digital currency / digital asset management and transfers
• Smart contract interaction
• etc.

Let's dissect the use case using the STRIDE threat modelling methodology.

‍

‍

(S)poofing

There are two parties to a transaction that can be spoofed - the user and the network. In case of the user, she is authenticated using her digital signature. Digital signature algorithms rely on asymmetric cryptosystems and involve a pair of keys - private and public. In blockchain network the user is represented by a public address which is derived from her public key. Blockchain node is responsible for verifying the signature provided alongside the transaction and  confirming that it was in fact signed by someone who has access to the private key.

Authentication of the network is a different problem. The network before the end-user is represented by the so-called network provider. Network provider are often TCP sockets that have a host and a TCP port and a RPC service bound to it. In some context, other types of providers (such as crypto wallets functioning as web browser extensions) can be used as proxies for convenience.

It's important to authenticate the providers because potential attackers can spoof them. In networks that don't provide confidentiality of data the risks of a successful spoofing attempt are limited to censorship / Denial of Service. But in case of using networks for processing confidential information, this might lead to confidentiality compromise.

‍

‍(T)ampering

Tampering the content of the transaction is extremely difficult in blockchain networks. Each transaction is signed using digital signatures and any change (even bit-flip) of the transaction's payload would result in signature invalidation.

Replay attacks can be considered a form of a tampering. These attacks rely on recording the signed transaction send to the network (such as "Send 1 bitcoin to user X") and then re-submitting the transaction back to the network in hopes of, in this example, sending more currency to user X.

Network nodes are responsible for mitigating this type of attack and it's usually done by including a nonce in a transaction that, once used, can never be re-used. Therefore, each subsequent attempt at re-submitting the transaction to the network would be rejected due to invalid (already used) nonce.

‍

‍

(R)epudiation

Non-repudiation means that neither side of the interaction can deny her actions.

When it comes to non-repudiation of user's actions, it's secured by the digital signature. If we assume that only owner of the private key knows it, then the non-repudiation is ensured.

Unfortunately, that's not always the case. Keys, wallets, seeds, passwords, certificates can be stolen. This eventuality alone allows a user to repudiate her actions. Security controls that can be used to mitigate resulting threats and risks are beyond the scope of this post, but the NIST-63A standard is a resource to refer to.

Network, on the other hand, can be held accountable for its "decisions" thanks to the e.g. transaction receipts. For example, in Ethereum each block that contains transactions accepted by the network also contains transaction receipts. Both transactions and receipts are secured against integrity loss using crypto algorithms. Therefore, it's easy to prove that the transaction took place by providing the transaction receipt.

‍

(I)nformation disclosure

Potential for unintentional information disclosure is significant threat in blockchain solutions. Often it's caused by using the technology without full understanding it's features. In public, permissionless networks such as Bitcoin or Ethereum blockchain data is globally available. This is a design choice for these networks as L1 solutions, without it achieving some of the goals (transparency, trust, decentralization) wouldn't be possible. It's extremely important to understand how transaction data is handled by specific blockchain solution before submitting it to the network. Especially when data contains:

• intellectual property
• personal data
• banking secrets
• other secrets

One significant threat related to the information disclosure is the compromise of a users's wallet (private key, seeding material for HDWallet, etc.). This is the most significant threat from the end-user's perspective. The wallet can be compromised in many various ways:

• User shared the seed unaware of the threats
• Malware infected user's workstation and exfiltrated wallet material to threat actor
• Wallet material was recovered from decommissioned drive using digital forensics
• etc.

It needs to be emphasized that the key security services of the blockchain solutions assume that user wallets are handled in a secure manner and are known only to their owner.

‍

(D)enial of Service

Responsibility of the availability of the service belongs to the network maintainer perspective.

[x - wallet degradation]

‍

(E)levation of privilege

Elevation of privilege is strictly dependent on the specific security model, permission definitions, roles, etc..

It can be argued that overspending is a specific type of privilege escalation. If define spending permission in terms of user's available balance, overspending can be considered a privilege escalation. Does the user have sufficient funds in her account? Is she in possession of a token that she wishes to transfer?

But these are the questions that belong either to the network maintainer or the service provider, since they're the ones who decide what "authorized" even means. Check the remaining articles in the series for more information on this.

‍

Threats in the end-user's threat model

Let's summarize the STRIDE reasoning by listing encountered threats that belong to the end-user's perspective and are not mitigated in other perspectives:

‍

1. Network spoofing

Impact: medium

Likelihood: medium

Overall risk: medium

Potential mitigating controls:

• Digital certificates - network providers should only allow connections over TLS and provide x509 certificates issued for their domain names. Applications processing user's transactions should verify providers that present invalid certificates. User's should only use network provider's that they trust.
• Provider configuration pinning - providing standard verified configuration for popular mainnets that can't be easily altered.

‍

2. Involuntary information disclosure

Impact: low

Likelihood: medium

Overall risk: low

Potential mitigating controls:

• Use of solutions that provide confidentiality / privacy (Hyperledger Fabric)
• Use of L2 solutions that provide confidentiality / privacy (state channels)
• Use of crypto commitments, ZK proofs
• Education / awareness programs

‍

3. Compromise of wallet confidentiality

Impact: high

Likelihood: high

Overall risk: high

Potential mitigating controls:

• hardware wallets
• multisig wallets with 1/1 configuration for easy replacement of compromised wallet
• optional handover of wallet custody

‍

4. Destruction of wallet

Impact: high

Likelihood: high

Overall risk: high

• multi-sig wallets with no minimum threshold of signatures
• optional handover of wallet custody

‍

Summary

I the threat modelling series I am hoping to create a systemic approach to identify the different aspects of threat models that exist in the blockchain sector. My goal is to expand on these aspects in my future posts to provide more in-depth insights.

The rationale behind breaking down threat models into perspectives are explained in this entry. Stay tuned for perspectives of service providers, network maintainers, operators and validators which should be even more interesting.

‍