<p>I have already identified a way to make an <a href="http://en.wikipedia.org/wiki/Secure_Digital" rel="nofollow noreferrer">SD card</a> truly read-only <a href="http://hackaday.com/2013/11/12/keep-your-sd-cards-data-safe-with-the-sd-locker/" rel="nofollow noreferrer">on HackaDay</a>.</p>

<p>So let's consider this situation:</p>

<ul>
<li>A third party have used <a href="http://en.wikipedia.org/wiki/Dd_%28Unix%29" rel="nofollow noreferrer">dd</a> to transfer the Linux image to an SD card</li>
<li>The <a href="http://hackaday.com/2013/11/12/keep-your-sd-cards-data-safe-with-the-sd-locker/" rel="nofollow noreferrer">PERM_WRITE_PROTECT</a> bit is set and can not be changed</li>
<li>There is a hash of the image that will be checked on booting from the card</li>
<li>The developer have signed the hash with PGP and this is clearly stated online</li>
</ul>

<p>The purpose of this card is to be able to boot a computer you already own and to know that what was intended to boot is actually running. Could <a href="http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface" rel="nofollow noreferrer">uEFI</a> or BIOS in a computer be compromised?</p>

<p>Security should enable the user to:</p>

<ul>
<li>Generate a paper wallet</li>
<li>Print the wallet with a USB connected printer</li>
<li>(Other actions needing high security precautions)</li>
</ul>

<p>To do this with confidence, both the SD card and <a href="https://bitcoin.stackexchange.com/questions/9112/how-can-i-verify-the-the-pgp-signature-of-bitaddress-org">the code</a> to generate the keys must be verified (hash and PGP signatures) by the user. What am I missing? Are there any loopholes in this combination of hardware and software?</p>

CC BY-SA 3.0
2013-12-25T04:56:19.890Z
To answer this question, you have to clearly articulate which elements you do and don't trust.  The Linux developers could have included a back door.  The BIOS could be malicious.  The printer could log all the pages it prints.  The USB cable could have a sniffer that logs all the bits going through it.  Et cetera.  Which of these possibilities concern you?
Nate Eldredge
CC BY-SA 3.0
2013-12-25T13:34:14.657Z
@nate-eldredge BIOS/UEFI would be my first concern, a "dumb" printer could be used (with no storage possibility). The last physical vulnerability that I take in to account is when the SD-card was written to by the third party. So sniffer USB cable is not included in my question. Niter is a hardware keylogger or any [Tempest](http://en.wikipedia.org/wiki/Tempest_(codename)) conserns included.
Jonas Oestman
CC BY-SA 3.0
2014-03-27T13:11:49.207Z
I have removed the three tags that you created for this question and added [tag:paper-wallet]. Please only add tags that are on-topic and will be useful in a broader scope on this SE.
Murch
<linux><paper-wallet><offline>
Making a read-only Linux SD card, where are the security loopholes? (offline key generation and signing)
Jonas Oestman
# Making a read-only Linux SD card, where are the security loopholes? (offline key generation and signing)

(Asked by: username_0 on 2013-12-25)

I have already identified a way to make an [SD card](http://en.wikipedia.org/wiki/Secure_Digital) truly read-only [on HackaDay](http://hackaday.com/2013/11/12/keep-your-sd-cards-data-safe-with-the-sd-locker/).

So let's consider this situation:

* A third party have used [dd](http://en.wikipedia.org/wiki/Dd_%28Unix%29) to transfer the Linux image to an SD card
* The [PERM\_WRITE\_PROTECT](http://hackaday.com/2013/11/12/keep-your-sd-cards-data-safe-with-the-sd-locker/) bit is set and can not be changed
* There is a hash of the image that will be checked on booting from the card
* The developer have signed the hash with PGP and this is clearly stated online

The purpose of this card is to be able to boot a computer you already own and to know that what was intended to boot is actually running. Could [uEFI](http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface) or BIOS in a computer be compromised?

Security should enable the user to:

* Generate a paper wallet
* Print the wallet with a USB connected printer
* (Other actions needing high security precautions)

To do this with confidence, both the SD card and [the code](https://bitcoin.stackexchange.com/questions/9112/how-can-i-verify-the-the-pgp-signature-of-bitaddress-org) to generate the keys must be verified (hash and PGP signatures) by the user. What am I missing? Are there any loopholes in this combination of hardware and software?

**Tags:** linux, paper-wallet, offline

> **Comments:**
> **username_1**: To answer this question, you have to clearly articulate which elements you do and don't trust.  The Linux developers could have included a back door.  The BIOS could be malicious.  The printer could log all the pages it prints.  The USB cable could have a sniffer that logs all the bits going through it.  Et cetera.  Which of these possibilities concern you?  
> **username_0**: @nate-eldredge BIOS/UEFI would be my first concern, a "dumb" printer could be used (with no storage possibility). The last physical vulnerability that I take in to account is when the SD-card was written to by the third party. So sniffer USB cable is not included in my question. Niter is a hardware keylogger or any [Tempest](http://en.wikipedia.org/wiki/Tempest_(codename)) conserns included.  
> **username_2**: I have removed the three tags that you created for this question and added [tag:paper-wallet]. Please only add tags that are on-topic and will be useful in a broader scope on this SE.  

---

## 0 answers

