1.
Client-Side Wallets in DApps
DApps: Architectures and Wallet
Interaction, Client-Side and Server-Side
Interaction with the Blockchain
Software University (SoftUni)
https://softuni.org
Svetlin Nakov
Blockchain Engineer
and Technical Trainer

2.
2
 Software engineer, trainer, entrepreneur,
PhD, author of 12 books, blockchain expert
 3 successful tech educational initiatives (100,000+ students):
About Svetlin Nakov

3.
3
 Technical advisor @ LockChain / LockTrip: https://locktrip.com
 Raised ~ 10.000 ETH in token sale (Sep-Nov 2017)
 Currently LOC token holders book hotels @ 20-30% better price
 Head of blockchain education (Jan-June 2018) @ Academy
School of Blockchain: https://academytoken.com
 Raised ~ 48M USD in token sale (Jan-Apr 2018)
 Tech advisor for blockchain crypto startups:
 Tokenize Exchange, Bountie, Weidex, IRIS Payments Solutions,
Aeternity Ventures
Nakov – Blockchain & Crypto Projects

4.
Table of Contents
4
1. Decentralized Blockchain Apps (DApps) Architectures
2. Server-Side Interaction with the Blockchain
3. Client-Side Interaction through MetaMask
4. Client-Side JS Wallet (using Ethers.js)
5. Live Demo: Voting DApp with Client-Side JS Wallet
6. Security Notes and Possible Attacks

5.
5
Decentralized Blockchain Apps (DApps)
DApps
Hold code + data on the
blockchain / p2p network
The front-end is still a
traditional app
Client App (front-end)
Smart Contract Backend
Code + data on the blockchain
Traditional Backend
Server-side code + data
HTTP
JSON RPC
JSON
RPC

6.
6
 Note: the server-side wallet signs all transactions  it might be subject
to hard hacker attacks  don't keep large amounts in it!
Server-Side Interaction with the Blockchain
Client App
(front-end)
Backend App
(JS / Java / C# / Python /
PHP / Ruby / Go / …)
RPC
Server
Wallet
Local geth /
Parity node
Or remote RPC,
e.g. api.infura.io
HTTP

7.
7
 Document Registry DApp
 Goal: keep a set of authentic documents on the blockchain
 Users can view / verify documents, published on the blockchain
 PDF documents hosted in decentralized storage (like IPFS)
 Document hashes published in a smart contract
 Admins can upload new documents
 Blockchain transactions are signed at the server-side
 Encrypted server-side wallet, unlocked by admin's password
Sample Scenario for Server-Side Interaction

8.
Client App
(front-end)
JS
Wallet
8
Client-Side Interaction through MetaMask
 Use MetaMask to protect private keys and sign transactions client-side
 MetaMask is currently unavailable on mobile devices!
geth / Parity node
at the server-side
Or remote RPC,
e.g. api.infura.io
HTTP
Backend App
(JS / Java / C# / Python
/ PHP / Ruby / Go / …)
RPC

9.
9
 The "CryptoKitties" Game
 Goal: view, purchase, breed and sell collectable items (kitties)
 https://www.cryptokitties.co
 Site visitors can browse the kitties, published on the blockchain
 Server-side logic reads the kitties from the blockchain
 Registered users can purchase / sell kitties
 MetaMask is used to sign transactions / interact with smart contracts
 MetaMask addon provides "Injected Web3 API" inside the browser
Sample Scenario for MetaMask Interaction

10.
10
 Using a client-side JS wallet (e.g. Ethers.js / LightWallet) simplifies the
interaction and delegates the security risks to the end-users
Client-Side Interaction with the Blockchain
geth / Parity node
at the server-side
Or remote RPC,
e.g. api.infura.io
RPCHTTP
Client App
(front-end)
JS
Wallet
Backend App
(JS / Java / C# / Python
/ PHP / Ruby / Go / …)

11.
11
 User registers in a mobile app / Web app
 A client-side wallet is created during the registration
 The wallet JSON is stored in the app / browser's LocalStorage
 Strong encryption (AES + Scrypt / Argon2), based on strong password
 Optionally the wallet JSON can be stored at the server-side or in
Dropbox / Storj / IPFS (readable by password-derived key)
 Security assumptions:
 The username, password & private key never leave the client app!
 All transactions are signed client-side, never at the server-side!
Client-Side JS Wallet

12.
12
 Voting App
 Users register and get a new random wallet (private key + address)
 The wallet JSON is stored at the server-side, after strong encryption
 The wallet password / private key never leave the client app
 User login  download the encrypted wallet JSON from the server
 After login / register, keep the encrypted wallet JSON in the browser session
 Logout  clear the browser session
 Use different passwords for server login and for the wallet (HMAC-derived)
 Lost password == lost wallet  no "reset password", use the mnemonics
Sample Scenario for Client-Side JS Wallet

13.
Live Demo: Voting DApp with
Client-Side JS Wallet
Source: https://github.com/nakov/client-side-ethereum-wallet
Demo: https://client-side-wallet-demo.herokuapp.com

14.
14
 The wallet server keeps: [WalletID  encrypted wallet (JSON)]
 WalletID = HMAC(username, password + 'server')
 Wallet password = HMAC(password, username + 'wallet')
 Client-side attacks
 Hacked laptop  stolen private key (it is decrypted to vote)
 Server-side attacks
 Hacked server  stolen JSON files  long password (derived from
username + pass) + unknown username  decrypting infeasible
 Still, hackers may inject malicious JS code in the client-side app
Security and Possible Attacks

15.
?
Client-Side Wallets in DApps
https://softuni.org

16.
License
 This course (slides, examples, demos, videos, homework, etc.)
is licensed under the "Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International" license
16

17.
Trainings @ Software University (SoftUni)
 Software University – High-Quality Education,
Profession and Job for Software Developers
 softuni.org
 Software University Foundation
 softuni.foundation
 Software University @ Facebook
 facebook.com/SoftwareUniversity
 Software University Forums
 forum.softuni.bg