Sallet - it protects your head
Desktop application of the 2 part cold storage solution system described below. Can be used as the frontend of my Raspi based Ice Cold wallet.
Sallet is for users aware of the importance of low level data. Users who are able to make decisions close the TX and UTXO scope.
Sallet is meant for users who do not like when 'user-friendliness' abstracts
away important information and hides substantial data from the conscious user.
Sallet is also for users who want to keep their Satoshis close to the chest.
It is a cold storage system, meaning:
-
private keys (and all data private keys can be derived from) are kept off-line
-
signing happens off-line
I’ll create a low-level off-line, off-chain bitcoin transaction handler. First and foremost a Cold storage system using up-to-date protocols.
Fundamental security assumption:The signing device touching private keys, signing transactions or handling random numbers is at all times:
running flawed software,
infected by malicous code,
harboring null-day-backdoors,
not able to generate proper entropy. In short, is an unpredictable and adversary actor on it’s own.
Obviously we still need to refine these assumptions, as a fully unpredictable machine can not be dealt with. We simply plan for the worst we can still handle.
Proposed solution to the assumpltion:we implement an air-gap after the adversary device. Anything is allowed to enter the device, nothing corrupted may leave it. The device is only allowed to communicate via analogue methods with the outside word.
Data meant to exit the device is turned into QR codes later to be displayed on a dedicated screen.
Entropy is off analogue source. Umpredicibility is dealt with using probability: Results of key management can and will be checked on regular basis against external sources. As we cannot handle all negative situations, we need to constantly audit possible worst cases, and adjust risk on higher levels by not creating transactions commanding more value, than what a possible attack on them may cost (even with the famous 'number-go-up' technology in mind!
- Isolation in detail
-
Signing device does not house hardware capable of wireless messaging, bluetooth, NFC or and mediumless data transfer methods. Device can additionally be shielded mechanically. Device will receive input over a camera in QR format only. Input is not the issue. The problem are input methods, that may unbeknownst to the user communicate outwards: We will not use UTP connections. Digital USB data transfer may only hapen using write protected SD cards. However write protection on most SD cards is OS (software) managed, it is not secure. Thus once used SD card should immediatelly be destroyed (Mission:Impossible). Most of the data entering the device AFTER installation is small enough to be represented as a small number of QR Codes.
- Scope of the isolation
-
Private keys, signatures, and random numbers are used, when Raw transactions are signed. Looking at the technical level, the adversary signing device only needs to receive Raw transactions and return signatures.
This does not mean, we have to limit the features of the signing device as long as not limiting it has other security advantages or user friendly features not affecting security. - Random number generation
-
Private keys are generated using
- Testing using probability
-
project will include automated tests to constantly monitor results of key generators against results of different online key generators. These will also test if code uses user-provided entropy. The same method will be used to check if signature module uses proper entropy.