A Spendable Cold Wallet from QR Video

Rafael Dowsley

, Myl

ene C. Q. Farias

1 a

, Mario Larangeira

3,∗

Anderson Nascimento

and Jot Virdee

Faculty of Information Technology, Monash University, Melbourne, Australia

Department of Electrical Engineering, Universidade de Bras

ılia, Brasilia, Brazil

Department of Mathematical and Computing Science, Tokyo Institute of Technology/IOHK, Tokyo, Japan

School of Engineering and Technology, University of Washington, Tacoma, U.S.A.

Keywords:

Digital Wallet, Cryptocurrency, Blockchain, QR Code.

Abstract:

Hot/cold wallet refers to a widely used paradigm to enhance the security level of cryptocurrency applications

that was proposed on Bitcoin Improvement Proposal 32. In a nutshell, after performing an initial setup in which

the hot wallet receives partial information of the cold wallet in order to hierarchically generate (transaction

receiving) addresses, the cold wallet stays ofﬂine, whereas the hot wallet is kept online. The initial transferred

information enables the hot wallet to generate receiving addresses for both wallets, but it can only spend its

own funds, i.e., it cannot spend the funds in the cold wallet. This design conveniently mimics money storage

in daily life: pocket money is kept in a less safe location, e.g., a regular wallet, while life savings are kept in

a more safe environment, e.g., banking account. Note that the funds that land in ofﬂine addresses cannot be

spent if the cold wallet is kept permanently ofﬂine. We propose a protocol and a technical solution to spend

funds from a cold wallet without physically connecting it to any network. We designed and implemented a

prototype for a system based on Optical Camera Communication (OCC) in a screen to camera setting, which

can receive messages from a computer screen at the rate of over 150kB per second. Our system consists of a

sequence of QR codes – a QR video. Our solution minimizes the possible attack vectors, including malware,

by relying on optical communication yet providing a larger bandwidth than regular QR code based solutions.

1 INTRODUCTION

The design of distributed ledgers based on blockchain

technologies is a hot research topic. Much of this

interest is due to the potential of such technologies

to enhance ﬁnancial systems worldwide, allowing a

more dynamic environment for the exchange of trans-

actions, leveraging modern network systems to fur-

ther automate banking systems. The central role of

this technology is to register activities, i.e., the trans-

actions, in a distributed network of nodes.

The Role of the Wallet. The wallet is the actual

component that generates the transactions and nor-

mally resides in mobile phones or desktop computers

of the users. This component manages the crypto-

graphic keys, (hierarchically) generates addresses, is-

sues transactions and does the accounting of the mon-

https://orcid.org/0000-0002-1957-9943.

∗

This work was supported by JSPS KAKENHI Grant

Number JP21K11882.

etary value stored in the addresses of the ledger. It

is a critical component, and security vulnerabilities

in the wallet can have devastating consequences that

cannot be solved in the consensus layer of blockchain

solutions. It is no wonder that a line of develop-

ment is the departure from pure software wallets to

hardware-based ones in order to avoid, or mitigate,

several common attack vectors such as malware and

tampering. However, comparatively, wallets have re-

ceived far less attention from the research community

than the consensus protocol.

Hybrid Approach: Hot/Cold Wallets. Hardware

wallets assure a higher level of security, however they

are not as convenient as their software counterpart.

In particular, some of its security emerges from be-

ing disconnected most of the time. It is accessed only

when issuing a new transaction, i.e., sign a message

with the cryptographic secret key. A common strat-

egy to obtain both convenience and security is to rely

on two wallets at the same time: “hot” and “cold”

Dowsley, R., Farias, M., Larangeira, M., Nascimento, A. and Virdee, J.

A Spendable Cold Wallet from QR Video.

DOI: 10.5220/0011138300003283

In Proceedings of the 19th International Conference on Security and Cryptography (SECRYPT 2022), pages 283-290

ISBN: 978-989-758-590-6; ISSN: 2184-7711

283

wallets. While the former is permanently connected

to the network, and therefore exposed to increased

security risks, the latter is permanently disconnected

(potentially a hardware wallet for enhanced security).

In this setting, as long as the cold wallet does not is-

sue a transaction, it is not required to be online, given

that the hot wallet can incorporate information from

the cold wallet to generate new (transaction receiv-

ing) addresses controlled without having to periodi-

cally receive secret information of the cold wallet.

This particular setting mimics the storage of ﬁat

money in our daily life: pocket money in our regular

wallet (the hot wallet) that is usually carried on daily

activities, and the savings account (the cold wallet),

which is kept in a much more secure environment. As

simple as the analogy is, it also suits the analogous use

cases for companies or exchanges which keep high

values in more static internal accounts, leaving the

more dynamic ones for the daily activities.

Cold Wallet Cannot Broadcast Transactions.

Part of the cold wallet conservative approach for se-

curity is to be permanently kept ofﬂine. In terms of

convenience of use, however, this is a limitation. The

capability of securely receiving funds is not affected,

given that the hot wallet has information regarding

the hierarchical cold wallet key generation and can

still generate fresh addresses for each single receiving

transaction. And other parties accessing the ledger

cannot link these transactions to a particular wallet. In

other words, the cold wallet can receive an unlimited

amount of funds securely using different addresses.

However, if the cold wallet is kept permanently of-

ﬂine (for security reasons), then it cannot issue any

transaction, as it cannot broadcast it in a convenient

and secure way. This work proposes an alternative

technique to circumvent this severe limitation.

1.1 Intuition of Our Solution: QR Video

We propose a solution in which the cold wallet is kept

permanently disconnected from the network, even

when issuing a transaction. Our wallet is not ex-

posed to malware or network risks since technically

it is never online. This seems to be counter intuitive,

however, in order to circumvent the early outlined re-

strictions, our protocol relies on a novel transmission

channel between the cold and hot wallets. Whereas

regular wallets connect with the ledger via a network

or hardware (e.g., USB cable), we devise a high ca-

pacity optical channel between wallets.

Although our approach provides an alternative for

isolating the cold wallet (thus obtaining a very strong

security level) while keeping desirable functionalities,

we should remark that it requires speciﬁc hardware.

It requires a camera and a display on both cold and

hot wallets in order to capture/transmit the optical in-

formation. Other solutions available on the market

rely on static code generation, i.e., regular QR codes,

which impose a strict limit of 4000 characters (De,

2018; NGrave, 2020; Khan et al., 2019). Our solution

yields a higher transmission rate since the hot wal-

let’s display generates a sequence of QR codes (i.e.,

a QR video) which are captured by the cold wallet’s

camera yielding a higher transmission capacity. To

the best of our knowledge, this work is the ﬁrst to

propose such an optical approach. This largely unex-

plored mean of communication prevents known ma-

licious attempts to access the secret information con-

tained in the device executing the cold wallet (as regu-

lar QR codes do, however our solution provides more

transmission capacity). The cold wallet uses its dis-

play to show the transaction’s information to the user.

If the user conﬁrms the transaction, it is signed inter-

nally by the cold wallet (and the state is updated). The

cold wallet’s display shows the QR video containing

the signed transaction, which is read by the hot wal-

let’s camera.

Our proposed channel based on optical commu-

nication has technical challenges of its own, which

required several adaptations, including the develop-

ment of the novel video approach. An urgent issue is

the size of the transactions, given that static QR codes

can contain a limited amount of data, and more mod-

ern systems may require larger addresses/transactions

(more on that later and in the work of Karakostas et

al. (Karakostas et al., 2020)). Additionally, the opti-

cal channel is very sensitive to the orientation of the

devices, which causes a high ratio of errors in the

transmission. A solution is to rely on error correcting

codes, which enlarges the data to be sent and therefore

renders the limited data capacity of QR codes even

more challenging. In order to solve these problems,

we have opted to introduce the concept of a QR video.

The QR video consists of a sequence of QR codes or-

ganized as frames of a video. By stacking several QR

code frames, we managed to transmit messages up to

100kB in less than a second. By adding a layer of er-

ror correction to our screen to camera communication

system, we end up with a robust and reliable solution.

We consider the introduction of QR video and

its application on hot/cold wallets the main technical

contributions of this work.

1.2 Related Works

The Bitcoin Improvement Proposal 32

(BIP32) (Wuille, 2017) introduced the Hierar-

SECRYPT 2022 - 19th International Conference on Security and Cryptography

284

chically Deterministic (HD) Wallet Standard. It

departed from ideas on deterministic wallets by

Maxwell et al. (Maxwell et al., 2014). Gutoski and

Stebila (Gutoski and Stebila, 2015) pointed out a

ﬂaw in BIP32 in the light of deterministic wallets

and proposed a ﬁx. However, they used a very weak

security model that does not consider the possibility

of the adversary getting to know public keys and/or

signatures corresponding to secret keys which were

not compromised. In addition, their security guaran-

tee is pretty weak (the adversary is only considered

successful if he manages to recover completely the

master secret key, instead of considering the standard

notion of unforgeability). Fan et al. (Fan et al., 2019)

also proposed a countermeasure to protect determin-

istic wallets. But their ad-hoc solution lacks a formal

analysis or security proof. Courtois et al. (Courtois

et al., 2014) presented a relevant review on the secu-

rity status of wallet implementations, and highlighted

how bad and correlated randomness can compromise

their security. Other results regarding the effects of

weak randomness were presented in (Brengel and

Rossow, 2018; Breitner and Heninger, 2019).

More recently, Das et al. (Das et al., 2019) pre-

sented a long overdue formal treatment of (ECDSA-

based) hot/cold wallet solutions that can be used with

legacy cryptocurrencies such as Bitcoin or Ethereum.

The formalization in (Das et al., 2019) differs from

the BIP32 speciﬁcation in the fact that the wallets

share a state. They proved that their solution satisﬁes

unforgeability and unlinkability properties: unforge-

ability guarantees that as long as the cold wallet is not

compromised, it is not possible to forge signatures to

authenticate new transactions as being signed with the

secret key corresponding to the cold wallet; while un-

linkability guarantees that public keys derived from

the same master public key are computationally in-

distinguishable from freshly generated public keys,

and thus a recipient can receive multiple transactions

without allowing other users to detect that the trans-

actions belong to the same recipient.

Special hardware is an alternative for enhancing

the security of wallets. Despite have been commer-

cially available for some time, only recently this type

of wallet has received a thorough formal analysis by

Arapinis et al. (Arapinis et al., 2019). In particular,

the authors considered attacks against the hardware

of the wallet in the UC framework. Marcedone et

al. (Marcedone et al., 2019) integrated two-factor au-

thentication into hardware wallet solutions. In the

realm of Proof-of-Stake (PoS), wallets potentially

have more actions at its disposal than only issuing

payment transactions (e.g., stake delegation). To the

best of our knowledge, only the work of Karakostas et

al. (Karakostas et al., 2020) proposes a thorough secu-

rity analysis in the UC Framework of PoS-based wal-

lets. As emphasized in (Karakostas et al., 2020), PoS

addresses are larger then regular BIP32 ones, because

they encode more information on staking delegation,

staking pools and etc, therefore our QR video based

solution, with higher transmission capacity, seem to

be a better ﬁt than QR code based ones.

2 STATEFUL HOT/COLD

WALLET SCHEME

For completeness, we review (Das et al., 2019) which

underpins our protocol to be presented in Section 3.

Deﬁnition 1 (Stateful Hot/Cold Wallet Scheme (Das

et al., 2019)). For a security parameter λ, a Stateful

Hot/Cold Wallet Scheme is deﬁned by the algorithms

(MGen,SKDer,PKDer,WSign, WVer) such that:

• The probabilistic master key generation algorithm

MGen takes as input the security parameter 1

and

outputs an initial state st

that is given to both hot

and cold wallets, a master public key mpk that is

given to the hot wallet, and a master secret key

msk that is given to the cold wallet;

• The deterministic secret key derivation algorithm

SKDer is run by the cold wallet to derive a ses-

sion secret key. It takes as input the master secret

key msk, the state st, identiﬁer ID, and outputs a

session secret key sk

and the new state st

;

• The deterministic public key derivation algorithm

PKDer is run by the hot wallet to derive a session

public key. It takes as input the master public key

mpk, the state st and an identiﬁer ID, and outputs

a session public key pk

and the new state st

;

• The probabilistic signing algorithm WSign is exe-

cuted by the cold wallet to sign messages. It takes

as input a message m and a session secret key sk

and outputs a signature σ;

• The deterministic veriﬁcation algorithm WVer is

executed by any party that wants to verify the va-

lidity of a signature. It takes as input a session

public key pk, a message m and a signature σ, and

outputs 0 (reject) or 1 (accept).

Remark. The identiﬁer ID is used to construct a new

public key pk

for an arbitrary choice of ID by al-

lowing a common secret string ch which is called

the “chaincode” between the wallets. As argued

in (Das et al., 2019; Maxwell et al., 2014), for the

ECDSA signature scheme, in order to derive a new

key pk

while preserving the unlinkability and un-

forgeability security properties (more about the se-

curity games in Section 3.3), it is necessary to com-

A Spendable Cold Wallet from QR Video

285

pute w ← H(ID,ch), pk

← mpk + w ·G and sk

←

msk + w, for a hash function H and ECDSA key pair

msk = x and mpk = x · G. For readability we omit the

value ch in the description of our protocol.

Correctness of a Stateful Hot/Cold Wallet Scheme.

The correctness requirement guarantees that if the

cold/hot wallets derive session key pairs on the same

set of identiﬁers ID

,.. .,ID

and in the same order

(departing from the initial state st

), then any signa-

ture created by the cold wallet using one of the session

secret keys sk

should be accepted when the veriﬁ-

cation algorithm is executed with the corresponding

session public key pk

. In other words, all the de-

rived session secret and public keys should match.

Remark. Later in our protocol we assume the ex-

istence of a deterministic function I : N → {0, 1}

∗

to generate unique identiﬁers ID

,.. .,ID

, to iden-

tify the key sessions between the wallets. Concretely,

given the sequential index i ∈ N, both wallets can

be kept synchronized by the correct generation of

values, i.e., executing I (i) = ID

. For an arbi-

trary ID

∗

value, the cold wallet can check the equality

I (i) = ID

= ID

∗

for sequential values i and conﬁrm

the correct index for the session key ID

∗

. This conﬁr-

mation procedure allow the pair of wallets to be kept

synchronized regarding the session keys.

Security of the Stateful Hot/Cold Wallet Scheme.

As described by Das et al. (Das et al., 2019), the

Stateful Hot/Cold Wallet Scheme should satisfy two

security properties: Unlinkability and Unforgeabil-

ity. Intuitively, the former protects the privacy of the

transaction receiver and captures the guarantee that it

should be infeasible to link transactions sending funds

to different session public keys that were derived from

the same master public key. It is required that an

adversary that is given the master public key cannot

distinguish between session public keys derived from

that master public key, and session public keys that

are generated from a fresh (i.e., independently and

randomly chosen) master public key. As highlighted

in (Das et al., 2019), such security property cannot be

achieved for keys which the adversary knows the state

used to derive them (the adversary can learn such state

if there is a breach in the hot wallet, for example).

The Unforgeability property captures the feature

that once funds are transferred to the cold wallet, they

remain secure if: (1) the hot wallet is breached; and

(2) the adversary observes transactions signed by the

cold wallet. Even such adversary cannot generate new

valid transactions spending funds from the cold wal-

let. Section 3.3 reviews the security games.

In this work, we focus on the orthogonal problem

of how to enable the cold wallet to generate spending

transactions without being connected to the network,

in a way that breaches of the cold wallet are avoided

while keeping it fully functional. We assume, as a

departure point, a Stateful Hot/Cold Wallet Scheme

that is correct, unlinkable and unforgeable.

3 THE QR VIDEO BASED

WALLETS

We now detail our proposed solution. Since our ap-

proach adds special features on both the cold W

cold

and hot W

hot

wallets, i.e., the camera and display

based communication, it is convenient to review the

traditional hot/cold setting with an unspendable cold

wallet (which contrasts with our spendable cold wal-

let approach) before we fully describe the protocol.

In a traditional hot/cold wallet setting the sensitive

information is handled by W

cold

, while W

hot

interacts

with the ledger and provides the required information

for generating a transaction (i.e., destination address,

amount, etc). Once the initial setup between wallets is

ﬁnished, they do not interact anymore. That setting is

convenient from the security point of view as the cold

wallet cannot broadcast transactions to the network.

In contrast, our cold wallet issues transactions and

interacts with the hot wallet through the optical/QR

video channel. This change in design has two major

consequences we need to address: (1) the introduc-

tion of a communication protocol between both wal-

lets; and (2) the guarantee that both wallets have the

necessary hardware to execute the protocol.

3.1 Description of the Setting

Communication. In our setting, after the initial

setup phase, the cold wallet W

cold

still interacts with

the hot wallet W

hot

, while keeping the secret-key. The

communication protocol is used for exchanging the

transaction attributes (from W

hot

to W

cold

) and for re-

ceiving the signed transaction (from W

cold

to W

hot

We remark that while W

cold

is only accessible via an

optical communication channel, W

hot

has a regular

network connection in addition to the optical commu-

nication channel with W

cold

Hardware Requirements. The cold wallet W

cold

communicates with W

hot

using a bi-directional optical

channel (a screen and a camera), and this is the only

mean of communication available for W

cold

(there is

no connection using USB cables, as common in hard-

ware wallets, NFC, WiFi, Bluetooth or other com-

SECRYPT 2022 - 19th International Conference on Security and Cryptography

286

munication channels). The consequence is that both

devices have to be equipped with camera and dis-

play. This optical channel allows connectivity while

severely limiting the actions of a potentially corrupted

hot

wallet. Furthermore, the display of W

cold

al-

lows an independent veriﬁcation of the received in-

formation by the user. A regular hardware-based wal-

let could in principle allow such interactivity using

a physical connection, however with disadvantages.

The most immediate drawback is that physical con-

nections are easier to explore in attacks. Moreover,

a cold wallet without a screen does not allow the in-

dependent veriﬁability of the exchanged information,

i.e., attributed and signed transactions.

3.2 The Communication Protocol

The starting point of our protocol is Deﬁnition 1;

however, our construction puts forth a protocol for the

exchange of messages between W

cold

and W

hot

aided

by the optical channel in order to allow W

cold

to gen-

erate signed transactions. The cold W

cold

and hot W

hot

wallets are described below. In the description of the

protocol, each interface also speciﬁes the equipment

activated on each phase. For simplicity, we left out of

the protocol description any sort of authentication be-

tween the two wallets. However we emphasize that a

key/credential exchange protocol between the wallets

can easily be added to the Initialization phase.

Cold Wallet W

cold

The cold wallet keeps variables for the

current state CurrentST and current identiﬁer

CurrentID, which are initialized as ⊥. It also

keeps two initially empty lists IDs and STs,

for identiﬁers and states.

Initialization: The user decides to

perform the initial setup. The proba-

bilistic master key generation algorithm

(mpk,msk,st

) ← MGen(1

) is executed

to generate the master public key mpk, the

master secret key msk and the initial state

. It then sets CurrentST ← st

, adds it to

STs and outputs in the display the message

that the initialization is complete without

showing any internal information.

Display Initialization (QR Video): The

user opens the optical channel to transmit the

master public key mpk and the initial state

to the hot wallet. The QR video encoding

this information is shown in the display.

Load Transaction Data (Camera): The user

chooses to receive the information regard-

ing a transaction, then it receives the QR

video which encodes (tx,ID,st). If ID ∈ IDs

and st ∈ STs, then set CandidateTX ← tx,

CandidateID ← ID and CandidateST ← st.

Otherwise

• set only CandidateTX ← tx, and

interactively execute (sk,st) ←

SKDer(msk,CurrentST, CurrentID)

and the identiﬁer generation function I ,

until I (i) → ID for some i;

• in the process, update accordingly the lists

IDs and STs, and the values CurrentST

and CurrentID;

• set CandidateID ← ID, and

CandidateST ← st.

Issue Transaction: The user veriﬁes the

transaction information tx that is shown in

the display and decides if it is approved or

not. If it is, execute (sk

CandidateID

,st) ←

SKDer(msk,CandidateST, CandidateID),

and signs the transaction σ ←

WSign(tx,sk

CandidateID

Deliver Transaction (QR Video): When the

user chooses to release the signed transaction,

then the wallet shows in the display the QR

video encoding (tx,σ).

Hot Wallet W

hot

The hot wallet keeps variables for the cur-

rent state CurrentST and current identiﬁer

CurrentID, which are initialized as ⊥. It also

keeps two initially empty lists IDs and STs,

for identiﬁers and states.

Initialization (Camera): The user chooses to

initialize the wallet and starts the camera. The

wallet then receives (mpk,st

) from W

cold

via

QR video, and sets CurrentST ← st

Generate Session Public Key:

The wallet runs (pk

CurrentID

,st) ←

PKDer(mpk,CurrentST, CurrentID), the

deterministic public key derivation algorithm,

to obtain the session public key pk

CurrentID

Then, with I and the newly generated state

st, it updates accordingly CurrentST and

CurrentID, and the lists IDs and STs.

Submit Transaction (Display QR Video):

Given a transaction tx, ID ∈ IDs and

A Spendable Cold Wallet from QR Video

287

st ∈ STs, generate a QR video which en-

codes (tx,ID,st) and make the transaction

tx available on the display.

Receive Signed Transaction (Camera): The

user chooses to receive the signed transaction

and starts the camera. The camera is expected

to read the QR video, which encodes (tx,σ).

Remark. The reader should notice that in the Gener-

ation Session Public Key phase, we purposely did not

highlighted the interface to be used by the hot wal-

let. The public key information is to be handled as the

receiving (often fresh) addresses for funds. It is not

to be used with W

cold

, therefore any regular mean of

communication can be used.

3.3 Security Games of the Protocol

By relying on the model of Deﬁnition 1, we can

also take advantage of the security analysis presented

in (Das et al., 2019). Namely, our construction inher-

its the security guarantees of that work, i.e., unlink-

ability and unforgeability. We observe that in (Das

et al., 2019) the authors remark that the games cap-

ture the case where the adversary receives signatures,

which is a condition not natural, given that the cold

wallet is usually kept ofﬂine. On the other hand, this

condition is concretely the case of our framework,

since we assume the QR video channel between the

cold and hot wallets, allowing the adversary to query

for signatures/transactions of its choice.

Regarding the proposed security games, intu-

itively, the Unlinkability Game Unl presents the ad-

versary with a signature from a wallet out of two pos-

sible, and it is requested to successively decide it, as in

a standard indistinguishability game. While the Un-

forgeability Game WUnf resembles the regular un-

forgeability property for signature schemes.

For completeness, we review the games from (Das

et al., 2019) in Tables 1 and 2. For the full secu-

rity discussion of the framework we refer the reader

to (Das et al., 2019).

4 IMPLEMENTATION: QR

VIDEO

We now describe our solution in more detail. Firstly

by describing the speciﬁcation of the prototype, then

we present pictures of the prototype in operation.

4.1 The Overall Setting

We divide the section in four items:

• The Reader: Description of the reader platform

and the limitations of it;

• The QR Codes: Here we describe the error cor-

rection codes, and the limits in the amount of data;

• The QR Video: The novel approach to increase

the data exchange ratio with video;

• The Hardware Setting: The hardware setting

where the experiments were conducted.

The Reader. We have implemented our QR video

reader by using the Google’s Barcode API. For the

sake of prototyping our solution, we have used an

Android cell phone. However, in practice, this de-

vice should be a dedicated one, working solely as a

wallet and not being connected to the internet at all.

We present a sequence of QR codes to the wallet in a

loop. Once a QR code is detected, it is then added to a

hash set. The hash set is used to prevent duplicate de-

tections. The API stops after it has reached 100,000

bytes which is thirty-ﬁve frames assuming each QR

code holds 2880 bytes. This idea is expanded later

in the QR video description. Once 100,000 bytes is

reached, the data in the hash set is converted into a

string and is then processed. The limit of 100kB was

chosen based on the fact that it is enough for reli-

ably transmitting the usual transactions appearing in

current blockchain platforms, but it could be trivially

modiﬁed to a larger number at the price of increasing

the duration of the optical transmission.

The QR Codes. The QR video holds QR codes gen-

erated with a 7% error correction rate (Reed-Solomon

code) and 1665 by 1665 pixels. In our tests, such

error correction rate was sufﬁcient to ensure a reli-

able communication between the wallets. Assuming

a generic case where words and spaces are used in the

QR code, Table 3 shows the largest amounts of data

each level can hold. Also, each QR code is generated

at the largest possible size, 177x177 modules.

The QR Video. A QR video is a video holding

multiple QR codes. Each frame holds a unique QR

code. The length of video varies depending on how

much data needs to be transferred. In our application,

100,000 bytes are needed, and split up into thirty-ﬁve

2880-byte QR codes. The codes are put together to

create a video. The video lasts about 600 millisec-

onds. The video is rendered at 60 frames/second due

to display constraints. Our transmission rate can be

computed as follows: 2880B × 60 = 172.8kB/s

SECRYPT 2022 - 19th International Conference on Security and Cryptography

288

Table 1: The adversary has access to two oracles, PK and WalSign, which respectively provides veriﬁcation keys for a given

session, and signatures for a given session.

Main WUnf Oracle WalSign(m,ID)

(st,msk,mpk) ← MGen(λ) If Keys[ID] = ⊥: Return ⊥

∗

,σ

∗

,ID

∗

) ← A

PK,WalSign

(mpk,st) (pk

,sk

) ← Keys[ID]

If Keys[ID

∗

] = ⊥ σ ← WSign(sk

,m)

Return 0 Sigs[ID] ← Sigs[ID] ∪ {m}

(pk

∗

,sk

∗

) ← Keys[ID

∗

] Return σ

If m

∗

∈ Sigs[ID

∗

]

Return 0 Oracle PK(ID)//Once per ID

If WVer(pk

∗

,σ

∗

) = 0 st

← st

Return 0 (sk

,st) ← SKDer(msk,ID,st

)

Return 1 (pk

,st) ← PKDer(mpk,ID,st

)

Keys[ID] ← (pk

,sk

)

Sigs[ID] ←

Return pk

Table 2: The adversary has access to the PK,WalSign,Chall, and getSt oracles which provides, respectively, newly generated

veriﬁcation keys for a given session, signatures for a given session, the challenge veriﬁcation key and the status of the hot

wallet.

Main Unl Oracle Chall(ID)//One time

(st,msk,mpk) ← MGen(λ) If StateQuery: Return ⊥

← {0,1}, Orc ← {PK,WalSign, Chall, getSt} If Keys[ID] 6= ⊥: Return ⊥

← A

Orc

(mpk) // Generate real key

If b

= b: Return 1 st

← st

Return 0 (sk

,st) ← SKDer(msk,ID,st

)

(pk

,st) ← PKDer(msk,ID,st

)

Oracle WalSign(m,ID) //Generate random key

If Keys[ID] = ⊥: Return ⊥ (

st,

msk,

mpk) ← MGen(λ)

(pk

,sk

) ← Keys[ID] (

,·) ← SKDer(

mpk,ID,

st)

σ ← WSign(m,sk

) (

,·) ← PKDer(

mpk,ID,

st)

Return σ Keys[ID] ← (pk

,sk

)

Return pk

Oracle PK(ID)

If Keys[ID] 6= ⊥ Oracle getSt

(pk

,sk

) ← Keys[ID] StateQuery ← True

Else Return st

← st

(sk

,st) ← SKDer(msk,ID,st

)

(pk

,st) ← PKDer(msk,ID,st

)

Keys[ID] ← (pk

,sk

)

Return pk

Table 3: Size of QR Codes in a Generic Case.

Error Correction Amount of Data Word Count

Level

7% 2880 bytes 403

15% 2331 bytes 315

25% 1663 bytes 230

30% 1273 bytes 171

Note that it takes a couple of seconds for the user to

align the camera with video and then hold a stable

position for the reader to recognize the QR codes. We

also remark that the QR video is looped for the user

to receive all the necessary data.

The Hardware Setting. For this prototype, two de-

vices were used. An android device to receive infor-

mation and a laptop screen capable of clearly display-

ing the QR video (sender). The Android uses its cam-

era at 1920 by 1080 resolution and 60 frames per sec-

ond to scan the QR video.

4.2 Images of the Prototype

Figures 1 and 2 illustrate our protocol running the

QR video in a mobile phone and computer setting

equipped with cameras and display.

A Spendable Cold Wallet from QR Video

289

Figure 1: Point of view use of the QR-Video scanner.

Figure 2: Side view use of the QR-Video scanner.

5 CONCLUSION

We proposed a new cold wallet communication set-

ting: an optical (display to camera) channel. In our

solution, a cold wallet equipped with a display and a

camera can receive transactions through camera, dis-

play the transaction to the user for conﬁrmation, sign

the conﬁrmed transactions, and display the signature

on its display which is, in turn, acquired by a hot wal-

let’s camera. Due to the size of the data transmis-

sion from the hot to the cold wallet, we proposed a

novel encoding information encoding scheme - a QR

video, i.e., sequence of frames containing individual

QR codes. Our solution achieves transmission rates

over 150 kB per second. Thus, our cold wallet can au-

thorize transactions not connected to the internet nor

wired to another device (e.g., through a USB port).

REFERENCES

Arapinis, M., Gkaniatsou, A., Karakostas, D., and Kiayias,

A. (2019). A formal treatment of hardware wallets. In

Goldberg, I. and Moore, T., editors, FC 2019: 23rd

International Conference on Financial Cryptography

and Data Security, volume 11598 of Lecture Notes in

Computer Science, pages 426–445, Frigate Bay, St.

Kitts and Nevis. Springer, Heidelberg, Germany.

Breitner, J. and Heninger, N. (2019). Biased nonce sense:

Lattice attacks against weak ECDSA signatures in

cryptocurrencies. In Goldberg, I. and Moore, T., ed-

itors, FC 2019: 23rd International Conference on

Financial Cryptography and Data Security, volume

11598 of Lecture Notes in Computer Science, pages

3–20, Frigate Bay, St. Kitts and Nevis. Springer, Hei-

delberg, Germany.

Brengel, M. and Rossow, C. (2018). Identifying key leak-

age of bitcoin users. In Bailey, M., Holz, T., Stam-

atogiannakis, M., and Ioannidis, S., editors, Research

in Attacks, Intrusions, and Defenses, pages 623–643,

Cham. Springer International Publishing.

Courtois, N. T., Emirdag, P., and Valsorda, F. (2014). Pri-

vate key recovery combination attacks: On extreme

fragility of popular bitcoin key management, wallet

and cold storage solutions in presence of poor RNG

events. Cryptology ePrint Archive, Report 2014/848.

http://eprint.iacr.org/2014/848.

Das, P., Faust, S., and Loss, J. (2019). A formal treatment

of deterministic wallets. In Cavallaro, L., Kinder, J.,

Wang, X., and Katz, J., editors, ACM CCS 2019: 26th

Conference on Computer and Communications Secu-

rity, pages 651–668. ACM Press.

De, N. (2018). Crypto Wallet to Replace Private Keys With

Encrypted QR Codes. https://www.coindesk.com/

markets/2018/07/27/crypto-wallet-to-replace-

private-keys-with-encrypted-qr-codes/. [Online;

accessed August-2021].

Fan, C.-I., Tseng, Y.-F., Su, H.-P., Hsu, R.-H., and Kikuchi,

H. (2019). Secure hierarchical bitcoin wallet scheme

against privilege escalation attacks. International

Journal of Information Security, pages 1–11.

Gutoski, G. and Stebila, D. (2015). Hierarchical determinis-

tic bitcoin wallets that tolerate key leakage. In B

ohme,

R. and Okamoto, T., editors, FC 2015: 19th Inter-

national Conference on Financial Cryptography and

Data Security, volume 8975 of Lecture Notes in Com-

puter Science, pages 497–504, San Juan, Puerto Rico.

Springer, Heidelberg, Germany.

Karakostas, D., Kiayias, A., and Larangeira, M. (2020). Ac-

count management in proof of stake ledgers. In Galdi,

C. and Kolesnikov, V., editors, Security and Cryptog-

raphy for Networks, pages 3–23, Cham. Springer In-

ternational Publishing.

Khan, A. G., Zahid, A. H., Hussain, M., and Riaz, U.

(2019). Security of cryptocurrency using hardware

wallet and qr code. In 2019 International Conference

on Innovative Computing (ICIC), pages 1–10. IEEE.

Marcedone, A., Pass, R., and shelat, a. (2019). Minimizing

trust in hardware wallets with two factor signatures.

In Goldberg, I. and Moore, T., editors, FC 2019: 23rd

International Conference on Financial Cryptography

and Data Security, volume 11598 of Lecture Notes in

Computer Science, pages 407–425, Frigate Bay, St.

Kitts and Nevis. Springer, Heidelberg, Germany.

Maxwell, G. et al. (2014). Deterministic wallets.

NGrave (2020). NGRAVE uses QR codes to keep

its hardware wallet 100% ofﬂine. https:

//medium.com/ngrave/ngrave-uses-qr-codes-to-

keep-its-hardware-wallet-100-ofﬂine-f1e18be317a2.

[Online; accessed August-2021].

Wuille, P. (2017). Hierarchical Deterministic Wal-

lets. https://github.com/bitcoin/bips/blob/master/bip-

0032.mediawiki. [Online; accessed July-2019].

SECRYPT 2022 - 19th International Conference on Security and Cryptography

290