Introduction

Pawket: A secure handy wallet, developing in the agile process.

When the Pawket team embarked on the ambitious journey of creating the best possible blockchain wallet designed for Chia, we started by defining a few design principles. Here are some of the guiding principles that helped us shape Pawket in its current form:

• No mandatory internet access. It should not include any scripts hosted on a third-party domain or require you to create a user account on the server. While some functionalities such as retrieving balances, starting transactions, and third-party integrations will always depend on internet access, the main function of signing transactions must remain usable in a closed network with no internet access.
• No secret key derivatives server-side. Even an encrypted or derived version of the user mnemonics or private key should never be sent or stored server side.
• Interoperable cryptography. A user must be able to take away any account with the tools of their choice, not just the one provided by us.
• Free and open source software. Both the client and the server should be fully available in an open source license. The software stack required to run the server should also be open source. The software should not include any mandatory proprietary component of any kind.
• Privacy by design. No tracking. The software should not store unnecessary personal information. The software should not report back user behavior or analytics to any third-party website unless the administrator or the user explicitly opt-in.
• Security by default. The solution should propose sane security settings by default. A power user can however still adjust the settings to match their security requirements and risk appetite.

If these principles are also important to you, there are good chances that Pawket will be the right fit. The rest of the document will provide you with information about the implementation details and associated risks so that you can make that call.

Application Architecture

Some knowledge about the different layers of the application is needed to better understand the attack surface. This section briefly explains the overall software architecture of Pawket.

Server

Pawket clients connect to the Light server by default, which provides a quick response without needing to synchronize the whole/selective blockchain.

The Light Server and the Syncer are developed in .Net 6.0, following the standard API design pattern. This server application relies on a Postgresql database, which cache and calculates the balance for clients.

Pawket clients are also allowed to connect to Full Node RPC, which could permit the client to connect to their trust Node to avoid API attacks. However, it could lose the benefit of the ability to get the balance quickly.

With Pawket Light Server, even dusted accounts can get balance instantly, thanks to Analytic DB in the backend, which is storing the analytic result of on-chain data by Syncer.

The data stored in Analytic DB is like this: (almost the same to the Chia SQLite DB)

erDiagram
    sync_coin_record {
        bigint id PK
        bytea coin_name
        bigint confirmed_index
        bigint spent_index
        bool coinbase
        bytea puzzle_hash
        bytea coin_parent
        bigint amount
        bigint timestamp
    }
    sync_hint_record {
        bigint id PK
        bytea coin_name
        bytea hint
    }
    sync_coin_record }o--o{ sync_hint_record : coin_name
    sync_coin_record }o--|{ sync_coin_record : coin_parent

Web Client

All data are stored in localStorage, and the sensitive information is encrypted with the User Master Password.

The web client also accepts API calls.

CLI

The Coin Manipulator can be reused to support CLI manipulation.

As Web Client is written in Typescript (a dialect of Javascript), it can be easily migrated to run in CLI with nodejs.

Blockchain Specific Design

Pawket is initially designed to serving Chia Network, however, the internal design is aim to be an universal blockchain account manager. We will describe chain specific design in this section.

Chia

Mnemonic

Pawket's master mnemonic is not compactible with Chia Official Wallet, even we simply allow the length of mnemonic to be 24 words, because they are indeed different generation process.

For Chia Official Wallet, looks like this:

graph LR;

    A("Mnemonic<br/>(24 words)")-->B[PBKDF2]-->C(Chia Private Key)

Indeed, Chia Official Wallet accept any type of text as input other than standard word defined in BIP39, because the whole process is just lots of HASH calculations.

For Pawket, looks like this:

graph LR;

    A("Mnemonic<br>(12 words)")-->D[BIP39<br/>Mnemonic to seed];
    D-->E["BIP39<br/>Entropy to mnemonic<br/>(24 words)<br/>[Chia Compatible Mnemonic]"];
    E-->B[PBKDF2]-->C(Chia Private Key);
    classDef pawket fill:#39C0AE,stroke:#FFFFAE;
    class D,E pawket;

Pawket strictly comply with BIP39 to gain better compatibility.

Design Consideration:

• Pawket designs to be chain-agnostic, so universal compatibility is important.
• Comply with BIP39, Pawket implements Shadow Wallet with greatest possible compatibility.
• Comply with BIP39, Pawket supports non-english mnemonic words naively.

Encryption

Pawket utilized the Chia's BLS curve(BLS12-381) and ECDH mechanism to create encryption algorithm, allow user to encrypt message with recipient's address, which only the recipient have ability to decrypt the message, just like the asymmetric encryption did.

With this mechanism, created a good user experience to send message to arbitrary activated address without communication or setup beforehand.

Here are notions:

• Synthetic Key: which is unique for each address in your wallet, it represents a synthetic child key of your root key.
• Synthetic Public Key: spk, the public part of synthetic key, can be calculate from synthetic private key and it is on-chain for every standard xch transaction.
• Synthetic Private Key: ssk, the private part of synthetic key, only the private key owner can calculate this key, can be used to decrypt message encrypted by synthetic public key.
• Activated Address: address with at least one coin is spent, that is one coin is sent from this address, and the spk was recorded on-chain.

Following is the procedure during encryption and decryption.

sequenceDiagram
    participant C as Chia Blockchain
    participant A as Alice
    participant B as Bob
    C ->> A: ❶ spk_B
    A->>A: ❷ shared = ssk_A * spk_B
    A->>B: ❸ spk_A, encrypted = enc(plain, shared)
    B->>B: ❺ shared = ssk_B * spk_A,<br/> plain = dec(encrypted, shared)

• ❶ Get Bob's spk from Blockchain, which requires activated address.
• ❷ Calculate the shared key according to ECDH.
• ❸ Send the encrypted message and Alice's spk.
• ❹ Calculate the shared key by Bob's ssk and Alice's spk according to ECDH, then decrypted the message.

Demonstration

Following is a demo of composite encrypted message:

-------- pawket.xch ---------
Sender Address: xch1ahu8zdwg03qadmk4tan653hxdjy596k6dy63wm0r6etj0g0y5uws4jwntt
Receiver Address: xch16xwqtf2d4jljks8lfpp4xnz8jak7jqjxc07y9tqlgt4grdp5hr4q7vcx3s
Encrypted Message: fd8ccb693c60e1ba3281c0d1a66c8539a537de6365ca685545052842626a5a1c

• Sender Address: from this address, program can find the spk_A from blockchain.
• Receiver Address: from this address, program can find the ssk_B from wallet.
• Encrypted Message: with shared key calculated by ECDH, the message can be decrypted.

Note: you can also refer to the source code.

General Security Principles

User Master Password

Used to decrypt local data containing the user data.

• Never stored in any server, nor any form of its derivatives.
• Never stored locally until the user enables “Remember”.
• Never transmitted over the internet.
• Master Password verification is delayed by PBKDF2-SHA2 to mitigate brute force crack.

User Data

Contains sensitive information including mnemonics and private keys.

• Utilize AES 256 for encryption and decryption.
• A salt for encryption is generated using a web crypto random function for each setup.
• The user data is stored in the web browser's local storage. This local storage is in turn stored on the user file system with the browser profile data.

Decrypted Data Usage

• Private keys are saved in memory without having to ask the user for Master Password each time.
• Private keys are sent from different instances through local storage or web sockets that utilize ECDH and AES.
• Memory protection depends on the browser’s security.

Communication

• All communication between Pawket wallet and Pawket servers is secured with HTTPS.
• Only insensitive information like spend-bundle, puzzle_hash, and coin_name can be sent to the server.
• Users are allowed to host the server on-premise for better security.

Air-gapped Signing

Only save your mnemonic on an offline device and sign using a QR code exchange.

Shadow Wallet

Fully compatible with BIP39, with shadow wallet support.

Super Light Wallet

Utilize server performance superiority, and mitigate the burden of Light Wallet to handle dusted accounts smoothly.

Single Mnemonic Multiple Accounts

With a single mnemonic, the user can create multiple accounts bootstrap with a sequence or shadow password.

Cross Platform

Support multiple platforms and cross-platform experiences.

dApp Integration

External API that allows other dApp to be easily integrated into the Chia Blockchain.

Risks Mitigation Strategies

Offline mode

The most important risk mitigation strategy is offline mode. Pawket can fully work in offline mode with degraded function. Only signing is allowed in this mode. The communication between offline devices and blockchain is through the QR code.

Fingerprint

Mnemonics and Account fingerprints are fully compatible with Official Chia Wallet.

Malicious Spend Bundle Discovery

When interacting with unfamous dApp, no reputation can be used to prove they are trustful to generate a safe spend bundle. With the coin analysis tool, Pawket can quickly find malicious coins or corrupted spend-bundle and give users a significant warning message.

Coin/Offer Analysis

Power users are also allowed to analyze coin/offer thoroughly.

TODO: add analysis UI image

Phishing

In this attack scenario, an attacker would create a page looking like a regular login page, or inject an additional javascript on a legitimate Pawket page.

Pawket mitigates this type of attack by using a "reserved security token". After the user is unlocked with the right password, the user will be welcomed with this "reserved security token". To prevent an attacker from placing a transparent input dialog on top of the input box, for example, to capture the passphrase, a field focus event displays an additional interaction in place with color changes.

Cross Site Scripting (XSS)

High on the list of web application vulnerabilities, an XSS vulnerability would allow an attacker to run arbitrary content on the page.

Persistent XSS

In this scenario, an attacker would submit malicious data to the server that would then be executed on the page when accessed by another user.

While Pawket server API would provide textual information and the Chialisp program. We assume it is the responsibility of the clients to treat the server information as hostile and take care of the sanitization.

In practice, in most cases, this means only rendering the information as text and using escaping facilities provided by the templating libraries used by Pawket (Vue) and template literals.

One common threat is the execution of the Chialisp program. First, the Chialisp program is designed to be a purely functional programming language, meaning no side effects exist so that no environment would be affected. Second, the Chialisp program would be executed in an iframe sandbox to avoid any possible affection.

Additionally, Pawket is preventing running inline javascript or including javascript files from third-party domains.

Reflected XSS

In this scenario, an attacker would craft a link (for example in an email) to run arbitrary code when the user navigates on the Pawket domain.

In certain cases, Pawket uses parameters provided in URLs. URL parameters are used, for example, to directly launch a send transaction (which allows 3rd party dApp to launch Pawket for sending) or accept an offer.

The attack surface for reflected XSS is reduced by running validation on the requested content, for example, the address of send target would be decoded by bech32m first, and the Chialisp program executes in the iframe sandbox.

Unsafe methods

The execution of javascript eval statements is not allowed.

SQL Injection

The server-side application seldom uses direct SQL queries but instead accesses the data through the framework ORM. By default, these database abstraction layers prevent most SQL injection issues. User input used by the ORM is always carefully validated. The remaining risks are mitigated using code reviews.

File upload

File upload is another sensitive area for web applications. Pawket at the moment only supports offer upload. The offer file size limit can be controlled by the administrator using the webserver environment variables.

CSRF

Cross-Site Request Forgery is an attack scenario where a user's action on a malicious third-party site would trigger a modification of data on a website, such as editing a resource or deleting it, crafting a malicious image URL, or having the user submit a form from another domain.

The Pawket server is stateless and authenticate-less, so no one can launch such an attack on the Pawket server.

Recovery risks

To recover an account a user must import their mnemonics and optional the accounts to regain access to their accounts. This process makes an attack scenario quite complicated but reduces the usability for the end user by introducing chances of losing access to the account permanently if the mnemonics are lost.

Source Control

Pawket utilizes git for source control, and Azure DevOps for fully automated CI/CD. Both codes in client and server have an adequate level of coverage. Tests are forced during the continuous integration process.

For every release, digital signatures are published to help the end-user or enterprise administrator ensure the integrity of each release.

Only a small amount of people are responsible and allowed to publish code. Before being pushed on a sensitive branch, each pull request is therefore reviewed and validated by different maintainers.

Bug bounty

When we have a sponsor, we will run a bug bounty program to further increase the security level.

Impact on Potential Attack Scenarios

Compromised Network

Man in the middle

If an attacker can break the TLS connection between the client and the server they will have access to the unencrypted data, and as such be able to capture the raw spend bundle for MEV or user-interested addresses for identity linking.

To reduce these risks a Pawket administrator must ensure that the server SSL configuration is configured to modern standards for example by disabling support for weak algorithms.

Compromised client

Memory access

Pawket does not protect the end user in a scenario where the attacker would be able to read the content of the memory on the client, e.g. a scenario where an attacker is capable of breaking the browser sandbox. Regular organizations should be fine by making sure the end user browsers are up to date and without malicious extensions installed.

Filesystem / keylogger access

Similarly, Pawket does not fully protect the end-user in a scenario where the attacker has read access to the local filesystem or has a keylogger installed. It would be possible in this scenario for example to gather the secret key from the local storage and the passphrase using a keylogger. Enforcing general end user endpoint security best practices (such as having an anti-virus in place, patched operating system, etc.) should be enough to mitigate the remaining risks to an acceptable level for most organizations.

Clipboard access

Similarly, Pawket cannot prevent another application or web extension with clipboard access right to listen to clipboard changes and protect the password if the user chooses to use this functionality in a compromised environment. Reducing the number of installed applications and extensions to a minimum is a good risk mitigation measure.

Input method

Very similar to keylogger, but this is much more common than that scenario. When importing mnemonics, one could commonly input mnemonics with an input method, but this could leak these sensitive mnemonics through the input method provider, especially when the input method would collect the inputs to do some analysis later. Using the system input method without collecting could save you.

Weak RNG

Pawket utilize browser built-in RNG (random number generator) for mnemonics generation (crypto.getRandomValues()). It's critical to have safe mnemonics by the safe RNG. Pawket does not protect the end user in a scenario where the attacker has changed the behavior of browser RNG.

Misconfigured client

Weak master password

At the moment there are no rules to enforce that a password must be strong even though it is encouraged. For example, it is possible for a user to setup a password with one digit.

Reserved Security Token

Our research shows that the majority of users do not understand the concept of phishing and therefore do not understand the concepts behind the reserved security token. Additional training and prompts may be required for this mechanism to be useful.

Malicious Web Application

Rogue vendor employee

An attacker with access to the Pawket server or CDN would be able to distribute a malicious web application. To mitigate this risk, every developer of the Pawket team must use a strong password, only with the approval of maintainers, the code can be published. Moreover, notifications are sent to the maintainers and committee after a publication.

Malicious dApp

Misleading Guide

When a transaction is raised by dApp, it may intend to give the user misleading guidance, and inject misleading text (e.g. "Official", "Pawket"). Pawket would give the user a visually distinguished area of dApp raised text.

Malicious Chialisp Program

All code is executed in the sandbox, it's safe to get the execution result of the Chialisp program. However, the generated UTXO may have a flaw, e.g. the UTXO can be transferred by an unauthenticated malicious adversary. Pawket has a built-in mechanism to check some common issues of spend bundles, but not all issues can be found. Users are encouraged to use dApp with reputation and audit reports to avoid this type of attack.

About Us

We are a group of experts in cryptocurrencies, analytics and engineering. Our main expertise lies in frontend, backend and blockchain development, as well as community building and customer service.