Verifying a Bitcoin Wallet Address

Leave a reply

Before sending someone a large sum of money on the internet via a irreversible transaction you better make sure you are sending the funds to the right address.

There are a few ways to go about doing this and depending on who you are sending funds to, how accessible their keys are and what the capabilities and behavior of their wallet software is you may need to choose different solutions.

Have the recipient sign a message using their wallet key

If we assume the recipient has the key associated with the target wallet online (aka not in cold storage) and that that the software they use for that wallet supports message signing with wallet keys this can be a viable option.

Unfortunately there is not currently a standard for the format of signatures using bitcoin keys with that said thankfully there appear to only be two common formats in-use today.

The first format being in-essence no formatting; client simply present you the three values you will need to verify a message and you do with them as you see fit, for example:

  • Wallet Address: 18neTpQ5MWnXg4n4rpoK5TgxXjEVcg2MYR
  • Message: [email protected] – my voice is my passphrase authenticate me
  • Signature: G0d6BnQem1gT4nd9esfsEyn1k/GfYAxDkNJmkNvmz8wCOI2Ncw9DvIcyP7OJcEvWbUHQNIBFK3V8wYdnhEFhYHI=

This format leaves a little be desired. For one you have to pass these values independently and then you also have issues around introduction of white-space which can invalidate signatures.

There is another increasingly common format that leverages ASCII armor and some codified rules to address these issues. This style of formatting originated in a project called Privacy Enhanced Mail (PEM), it was one of the first proposals for how to sign and encrypt mail on the Internet and was later adopted by PGP (RFC https://tools.ietf.org/html/rfc4880).

But don’t confuse this format with these other formats they follow some different rules when it comes to encoding.

What this means is that depending on the implementation of the wallet software the recipient uses you may not be able to validate the signature they produce without some manipulation of the text.

As for what this format looks like, its fairly straight forward:

-----BEGIN BITCOIN SIGNED MESSAGE-----
[email protected] - my voice is my passphrase authenticate me
-----BEGIN SIGNATURE-----
18neTpQ5MWnXg4n4rpoK5TgxXjEVcg2MYR
G0d6BnQem1gT4nd9esfsEyn1k/GfYAxDkNJmkNvmz8wCOI2Ncw9DvIcyP7OJcEvWbUHQNIBFK3V8wYdnhEFhYHI=
-----END BITCOIN SIGNED MESSAGE-----

The core differences with this format (as specified in this thread and the PGP rule-set are:

  • No “empty-line” delineator between the headers and message;
  • Beginning and end whitespace / newlines ignored excluded when verifying the signature;
  • Length of rows are not limited to 80 characters;
  • No concept of header values (like versions).

The reason I point this out is that since there really isn’t a standard for this signature format and the format diverges from what has been used historically you may still encounter interoperability issues when validating messages between clients that have not been tested with each other.

With that said when you have managed to successfully verify a message like this you know that whoever produced the message owns the key associated with the wallet associated with it.

To address the risk of a message substitution the sender would need to communicate a challenge out of band to the recipient. For example you may notice in my message above I included “my voice is my passphrase authenticate me”. My inclusion of this message (presumably exchanged out of band) helps assure the sender that it was me who signed the message.

To make this process a little easier Andrew Yanovsky and I put together a simple site that can validate both formats, it’s all client side so you can save the files locally and run without the dependency on the website if you like.

NOTE: It is worth noting that this workflow does not accommodate P2SH and multi-signature wallets both of which will see increased use as time progresses.

Do a micro-transaction

The simplest way to verify an address is to simply send a small amount of money to that address and verify out of band with the recipient that they confirm seeing it in their balance. This is what most online payment services but again this requires the keys to be accessible to the sender they can perform the transaction.

There are a few things to keep in mind if you go this way, specifically:

  1. Don’t send less that .0001 BTC because the transaction may get “stuck” and not be processed.
  2. Be sure to include some transaction fee even if tiny so it doesn’t stay unprocessed for too long.

Once the transaction has been sent and you use a tool like blockchain.info to see that the transaction has been confirmed you can verify out of band with the address owner again that they see the funds as well.

This approach unlike the wallet signing key approach can also work with multi-signature and P2SH wallets which will be in use increasingly as clients better support these techniques.

Verify the wallet address two times via out of band channel

If they keys are offline (in cold storage) the only viable option is to carefully validate each character of the address via an out of bound secure channel, I would personally not rely on this approach for large sums but if both parties are careful it can work. By doing the check twice you reduce the chance of human error but mistakes can happen and in this case they can not be undone so use this approach with caution.

None of these solutions are perfect and moving forward I expect we will see services like OneName.io and exchanges with authenticated account profiles will become the way that we solve these problems but in the mean time you can reasonably manage the transaction workflow via these two mechanism.

Certificate Path Building in PKIjs

Leave a reply

Now that its possible to decode and verify the signature on X.509 certificates within the browser the natural question to ask is what can I do with that?

Well first off to build an interesting application you will need to have the ability to validate that a certificate is trusted the first step in doing that is building the certificate path associated with the certificate.

The defacto standard for path building libraries is the NIST PKITS tests our goal is to create a library that will be able to pass the sane tests from this suite (some are odd for sure).

This is a pretty high bar and will take some time. At the time of writing this blog post we pass 1-33 of this test suite in with flying colors these tests cover all of the basic certificate validation rules. We also think the library will pass all Policy Constraints and Name Constraints but more testing is needed to confirm.

So how does building a chain look like today with this library?

var certs = new Array();

// Load cert to be validated, its intermediates and root
for(var i = 0; i < cert_buffers.length; i++)
{
    var asn1 = org.pkijs.fromBER(cert_buffers[i]);
    certs.push(new org.pkijs.simpl.CERT({ schema: asn1.result }));
}

var crls = new Array();

// Load any CRLs we have
for(var i = 0; i < crl_buffers.length; i++)
{
    var asn1 = org.pkijs.fromBER(crl_buffers[i]);
    crls.push(new org.pkijs.simpl.CRL({ schema: asn1.result }));
}

var cert_chain_simpl = new org.pkijs.simpl.CERT_CHAIN({
    certs: certs,
    crls: crls
});

cert_chain_simpl.verify().then(
    function(result)
    {
        alert("Good result");
    },
    function(error)
    {
        alert("Error: " + error);
    }
);

The current incarnation of the API expects that the bag of certificates that is passed in will include all intermediates as well as all trust anchors. We will be changing this in a future release so that trust anchors are passed in another bag.

This will help ensure that the certificate inputs to be validated don’t contain anything that might accidentally result in the certificate being treated as valid when it should not be. With that said as it is currently structured we can begin developing automated testing which is great.

Note: Updated the post to indicate the goal is to pass the sane PKITS tests, some of which are not and some are not possible to pass in a web environment.

MUST STAPLE and PKI.js

Leave a reply

The other day I did a post on how to create a self-signed certificate using PKI.js in that sample we included a Basic Constraints extension but we could have also just as easily defined a custom or new certificate extension. For example thanks to #heartbleed folks are talking about MUST STAPLE again, this is an extension that was proposed several years ago that when present would indicate that clients should hard-fail instead of soft-fail with OCSP.

This proposal is based on a generic concept of expressing a security policy within the certificate. While the OIDs for this extension and the associated policy have not been defined yet one can easily construct a certificate using this extension with PKI.js:

cert_simpl.extensions.push(new org.pkijs.simpl.EXTENSION({
    extnID: "1.2.3", // No OIDs assigned yet
    critical: false,
    extnValue: (new org.pkijs.asn1.SEQUENCE({
        value: [
                   new org.pkijs.asn1.INTEGER({ value: 4 }),
                   new org.pkijs.asn1.INTEGER({ value: 5 }),
                   new org.pkijs.asn1.INTEGER({ value: 6 })
               ]
               })).toBER(false)
}));

NOTE: In the above snip-it we just made up two OID values, hopefully IANA will assign OIDs soon so it is possible for browsers and CAs to implement this extension formally.

Why shouldn’t you use safe-deposit boxes to store Bitcoin?

Leave a reply

Banks are not exactly what they used to be. I don’t know exactly when it changed but as a boy I remember banks being these massive buildings with large vault doors, armed guards and cameras everywhere but it seems increasingly they are located in strip malls right next to a Great Clips with nothing more an alarm and a small safe in the back. Frankly most don’t even offer safe deposit services any longer.

The lack of security of these facilities offer is not why I don’t recommend their use; it is because they can’t be trusted to keep your valuables safe. Not only can the federal government seize the contents of these safe deposit boxes at will increasingly the state governments are doing so as well as a means to shore up their own finances via their unclaimed property programs.

You can mitigate some of these risks by using techniques like Shamir Secret Sharing to split your keys up into M of N parts or by utilizing multi-signature wallets where the parts or keys are stored at different facilities reducing the likelihood of these events impacting you (which you should do regardless) but as a general rule I recommend use of private facilities instead.

Private facilities have a number of value propositions above and beyond banks, these include:

  1. Not regulated which makes it more difficult for the contents to be frozen or seized
  2. Identification is often not a requirement to open an account making targeting assets in the vault more difficult
  3. Not subject to bank holidays (for example during 9/11 banks were closed in the US)
  4. May offer:
    1. Insurance that would protect you from loss;
    2. Improved security protections and procedures;
    3. 24x7x365 access to the facility;
    4. 24x7x365 armed guards;
    5. The use of “ceremony rooms” where you can privately perform transactions.

Above these value propositions a few things to keep in mind when looking at these facilities are:

  1. Do they offer dual key control? This is when they keep one key and you keep the other. This helps mitigate the risk of your key being stolen.
  2. Did they their ceremony rooms offer you sufficient confidentiality and space to perform your transactions?
  3. Do they limit how many people can be in the vault at a given time?
  4. Is the construction of the facility done in such a way that physical compromise would be difficult?
  5. Do they have adequate camera coverage and keep the recordings long enough to be useful to identify compromise?
  6. Do they follow strict procedures or are they overly lax?
  7. Do they have any attempted thefts and if so how were they handled?
  8. Have their ever been any legal claims from their customers?
  9. What are the BBB & Yelp reports for the facility?

Regardless of which facilities you choose to store your Bitcoin assets its also important to remember the old adage of “Trust but verify” and periodically access the assets to ensure their integrity and availability.

 

Generating signed messages using CMS and PKI.js

Leave a reply

One of the most common signature formats on the web is known as CMS SignedData, this is the signature format used in PDF files, CAdES, S/MIME and several other digital signature solutions.

As a signature it has a few notable features:

  1. Having multiple signers.
  2. Including meta-data that will be signed along with the data that is being signed.
  3. Including meta-data that is outside the scope of the signature.
  4. Signing data contained within the signature or data referenced by it.

These traits mean you can do some interesting things like implementing counter-signing in-turn enabling notarization scenarios.

Utilizing PKI.js you can now create and verify this signature format, bellow is an example of how creating one of these messages looks using this library:

// #region Put a static values 
var sample_data = new Uint8Array(sample_data);
sample_data[0] = 0x00;
sample_data[1] = 0x01;
sample_data[2] = 0x02;
sample_data[3] = 0x03;
sample_data[4] = 0x04;

cms_signed_simpl = new org.pkijs.simpl.CMS_SIGNED_DATA({
    digestAlgorithms: [
        new org.pkijs.simpl.ALGORITHM_IDENTIFIER({ algorithm_id: "1.3.14.3.2.26" }) // SHA-1
    ],
    encapContentInfo: new org.pkijs.simpl.cms.EncapsulatedContentInfo({
        eContentType: "1.2.840.113549.1.7.1", // "data" content type
        eContent: new org.pkijs.asn1.OCTETSTRING({ value_hex: sample_data })
    }),
    signerInfos: [
        new org.pkijs.simpl.CMS_SIGNER_INFO({
            sid: new org.pkijs.simpl.cms.IssuerAndSerialNumber({
                issuer: cert_simpl.issuer,
                serialNumber: cert_simpl.serialNumber
            }),
            digestAlgorithm: new org.pkijs.simpl.ALGORITHM_IDENTIFIER({ algorithm_id: "1.3.14.3.2.26" }), // SHA-1
            signatureAlgorithm: new org.pkijs.simpl.ALGORITHM_IDENTIFIER({ algorithm_id: "1.2.840.113549.1.1.5" }), // RSA + SHA-1
        })
    ],
    certificates: [cert_simpl]
});
// #endregion 

return cms_signed_simpl.sign(privateKey, 0);

In this sample you can see we are putting our content to be signed within the SignedData message and then signing it with RSA and SHA1, this is in-the exact same thing that is needed to implement what is called opaque signed email in S/MIME.

 

Frankencerts, new extensions and PKI.js

2 Replies

One of the things that we wanted you to be able to use the PKI.js libraries for is the X.509 Certificates, including those with new extensions (like testing for OCSP MUST Staple or for testing other certificate processing libraries like was done in the Frankencert paper.

Here is an example of what that might look like:

function create_cert()
{
    // #region Initial variables 
    var sequence = Promise.resolve();

    var cert_simpl = new org.pkijs.simpl.CERT();

    var publicKey;
    var privateKey;
    // #endregion 

    // #region Get a "crypto" extension 
    var crypto = org.pkijs.getCrypto();
    if(typeof crypto == "undefined")
    {
        alert("No WebCrypto extension found");

        return;
    }
    // #endregion 

    // #region Put a static values 
    cert_simpl.serialNumber = new org.pkijs.asn1.INTEGER({ value: 1 });
    cert_simpl.issuer.types_and_values.push(new org.pkijs.simpl.ATTR_TYPE_AND_VALUE({
        type: "2.222.333",
        value: new org.pkijs.asn1.PRINTABLESTRING({ value: "RU" })
    }));
    cert_simpl.issuer.types_and_values.push(new org.pkijs.simpl.ATTR_TYPE_AND_VALUE({
        type: "2.222.444",
        value: new org.pkijs.asn1.PRINTABLESTRING({ value: "Test" })
    }));
    cert_simpl.subject.types_and_values.push(new org.pkijs.simpl.ATTR_TYPE_AND_VALUE({
        type: "2.222.333",
        value: new org.pkijs.asn1.PRINTABLESTRING({ value: "RU" })
    }));
    cert_simpl.subject.types_and_values.push(new org.pkijs.simpl.ATTR_TYPE_AND_VALUE({
        type: "2.222.444",
        value: new org.pkijs.asn1.PRINTABLESTRING({ value: "Test" })
    }));
    cert_simpl.notBefore.value = new Date();
    cert_simpl.notAfter.value = new Date(2016, 01, 01);

    cert_simpl.extensions = new Array(); // Extensions are not a part of certificate by default, it's an optional array

    // #region "BasicConstraints" extension
    var basic_constr = new org.pkijs.simpl.x509.BasicConstraints({
        cA: true,
        pathLenConstraint: 3
    });

    cert_simpl.extensions.push(new org.pkijs.simpl.EXTENSION({
        extnID: "2.5.29.19",
        critical: false,
        extnValue: basic_constr.toSchema().toBER(false),
        parsedValue: basic_constr // Parsed value for well-known extensions
    }));
    // #endregion 

    // #region "KeyUsage" extension 
    var bit_array = new ArrayBuffer(1);
    var bit_view = new Uint8Array(bit_array);

    bit_view[0] = bit_view[0] | 0x02; // Key usage "cRLSign" flag
    bit_view[0] = bit_view[0] | 0x04; // Key usage "keyCertSign" flag

    var key_usage = new org.pkijs.asn1.BITSTRING({ value_hex: bit_array });

    cert_simpl.extensions.push(new org.pkijs.simpl.EXTENSION({
        extnID: "2.5.29.15",
        critical: false,
        extnValue: key_usage.toBER(false),
        parsedValue: key_usage // Parsed value for well-known extensions
    }));
    // #endregion 

    cert_simpl.signatureAlgorithm.algorithm_id = "1.2.840.113549.1.1.5"; // RSA + SHA-1
    cert_simpl.signature.algorithm_id = cert_simpl.signatureAlgorithm.algorithm_id; // Must be the same value
    // #endregion 

    // #region Create a new key pair 
    sequence = sequence.then(
        function()
        {
            return crypto.generateKey({ name: "RSASSA-PKCS1-v1_5", modulusLength: 2048, publicExponent: new Uint8Array([0x01, 0x00, 0x01]), hash: { name: "sha-1" } }, true, ["encrypt", "decrypt", "sign", "verify"]);
        }
    );
    // #endregion 

    // #region Store new key in an interim variables
    sequence = sequence.then(
        function(keyPair)
        {
            publicKey = keyPair.publicKey;
            privateKey = keyPair.privateKey;
        },
        function(error)
        {
            alert("Error during key generation: " + error);
        }
    );
    // #endregion 

    // #region Exporting public key into "subjectPublicKeyInfo"  
    sequence = sequence.then(
        function()
        {
            return cert_simpl.subjectPublicKeyInfo.importKey(publicKey);
         }
    );
    // #endregion 

    // #region Signing final certificate 
    sequence = sequence.then(
       function()
       {
           return cert_simpl.sign(privateKey);
       },
       function(error)
       {
           alert("Error during exporting public key: " + error);
       }
    );
    // #endregion 

    sequence = sequence.then(
        function()
        {
            alert("Good result");
        },
        function(error)
        {
            alert("Error during signing: " + error);
        }
    );

    sequence.then(
        function()
        {
            return cert_simpl.verify();
        }
    ).then(
        function(result)
        {
            alert("Verification passed: " + result);
        },
        function(error)
        {
           alert("Verification failed: " + eror);
        }
    );
}

As you can see the library is designed in such a way you are not limited to the creation of some static pre-conceived layouts of these structures, you can fairly easily construct any type of certificate (or any of the other supported message types).

At a later date (if it makes sense to do so) we may also decide to add a simple layer ontop of this that abstracts out the need to understand encoding concepts as well.

This layered approach ensures the library can be used to create real-applications without the need to hack up the underlying APIs enabling developers to avoid the need to understand low-level  ASN.1 formats in detail.

Potential projects for PKI.JS

Leave a reply

This is a list of potential projects that would benefit from PKI.js, can you think of any others that would be interesting?

  1. Adding signing, time-stamping and verifying support to pdf.js.
  2. Creating a smime.js on email.js that provides signing, verifying, encryption, decryption of S/MIME.
  3. Creating a CAdES library for web pages.
  4. Adding signature support to web document management solutions.
  5. Adding encrypted mail support in webmail offerings.
  6. Building a usable and modern certificate based authentication solution using web markup for credential selection.
  7. Creating a rich user experience for the short-lived certificates providing temporary access via SSH and TLS.

With some changes the libraries could be used in server side projects:

  1. Creating an OCSP responder based on node.js.
  2. Creating a simple CA on node.js

WebCrypto and PKI

Leave a reply

Like it or not here it comes — within the next few months WebCrypto will be supported in various degrees across all mainstream browsers. There are plenty of posts out there talking about the security concerns of performing cryptography in the browser so I wont go into those here.

What I wanted to talk about was now that it’s here (mostly) what can we do with it? There will be those who say you do harm by making any claims about the assurances a web application makes relating to identity and confidentiality when WebCrypto is involved. The reality though is its happening and we should think about how we enable applications to use it responsibly.

This is why I started work on PKI.JS and ASN1.JS with Yuri Strozhevsky. Now that browsers have these basic crypto primitives available to them it is possible to build web applications that are interoperable with the security services used off the web, it is also possible to build new services on the web that simply were not possible before.

Now there have been libraries that that offered ASN.1 and PKI related capabilities (for example jsRSAsign, Forge and Lapo-asn1js) but none of these were complete and none built around WebCrypto as the source of crypto.

What Yuri and I set out to do is create a set of libraries that addressed these gaps and used public test suites (when available) to ensure conformance with the associated standards, including:

  1. X.509 and CRLs– RFC 5280
  2. CMS / PKCS 7 (Signed & EnvelopedData) – RFC 5652
  3. PKCS10 – RFC 2986
  4. PKCS8 – RFC 5208
  5. OCSP – RFC 6960
  6. Time-stamping – RFC 3161

For example for ASN.1 Yuri used his freely available test suite and for path building he tested against the PKITS test suite.

This of course does not mean the libraries are 100% compliant or defect free, in-fact I can promise you they are not but where test suites were clearly available we tried to utilize them so we would end up with a highly stable and standards compliant library.

At this point the libraries work in all modern browsers but only support signing, verifying, encrypting and decrypting in the Chrome dev-channel but in theory should work on Firefox nightlies as well. Unfortunately the profile and version of WebCrypto supported by Internet Explorer is outdated enough at this point these features do not work there at all yet.

These libraries have not yet been published to their public repositories but I expect them to be within the week under an BSD style license, to give some perspective on the size of this project I expect it to be just under 20,000 lines of code when released. It’s my hope that other people take this and build upon them so that the Internet has a browser friendly way to interact with these technologies.

NOTE: While I hate disclaimers like this but these libraries have not undergone any significant review please do not consider them production ready more work is needed before that’s the case.

NOTE: It’s also worth noting that until at least two browsers release their WebCrypto implementations as final products that these libraries may stop working or not work uniformly across browsers, for example at this time the nightly Chrome builds do nor support key exports which prevents implementation of the key storage structures.

P.S I actually miss spoke earlier, we did not end up include PKCS #12 in this version but most of the base structures are supported.

The bias of experience and ignorance of youth

Leave a reply

It was really security (well pirate and BBS’s and IRC channels) that first got me seriously into computers. It was a place where I was surrounded with brilliant people and super interesting problems to explore. It did not take long for me to discover cryptography. I remember the first time I encountered the concepts; I was working on cracking a game and the publisher actually had encrypted some of the instructions and I had to figure out what it was they had used, how it worked and how to work around it.

At that moment I was hooked. Since then nearly every professional experience I have had has been in computer security — simply put I love this stuff.

As it turns out most of the last two decades I have ended up working on authentication systems of one sort of another; these end up being interesting applications of protocol design, performance design patterns and cryptography.

The nature of these spaces also resulted in me working on operating systems and security services which in turn led me to have a strong bias against the “web developers” who I viewed largely as script kiddies with no understanding of computer science fundamentals let alone security. So much so I discouraged my son from learning many of the associated technologies because “real programmers” don’t bother with such things.

There has been an amazing shift over the last decade and even if at one point I was right for the above position I certainly would not be today. Not only have the technologies that are used to make up the web evolved to the point that they are as impressive and powerful as many of their native counterparts but many of the engineers working with them have become world-class as well.

This has led to some interesting trends the most poignant being the adoption of Javascript as a language for use outside of the browser like in Node.JS and the Tessel. This has been enabled by a competitive race to build the fastest experience on the web, which has become totally dependent on Javascript.

As a technologist I love this as it makes technology more approachable, it makes it easier for things to be rapidly be built and creates portability of skill across the layers of an engineering project.

As a security practitioner it gives me pause; those of you who know me one of my favorite sayings is “Just because you can, doesn’t mean you should” and since this approachability and increased speed of innovation has obvious and natural negative implications when securing systems I am hesitant still to embrace it fully.

I take solace in this dichotomy because of something my mom would always tell me – You’re not learning if your not falling.

As we look at the features in HTML 5 and their support of things like WebCrypto, WebSockets and (god forbid) WebGL I try to remind myself how important it is not to let our personal biases hold back innovation while holding onto the rational and caution approach of my inner security practitioner.

Bitcoin Paper Wallets and Digital Backups

Leave a reply

The folks working on Armory have done a wonderful job thinking about many of the risks associated with Bitcoin and Paper Wallets. The have even gone as far to consider the risks of a compromised printer with a feature they call SecurePrint™.

In the Certificate Authority world when managing secrets that can not be kept within a Hardware Security Module (HSM) we go a further by using similar key management tools on Tempest hardware physically located in Faraday cage under rigorous ceremonies designed to ensure every single step performed is confidential, verified and audited.

For the individual moderate Bitcoin holdings Armory provides a robust story for managing wallet keys and producing paper wallets especially when paired with something like the PiWallet. That said since once doesn’t need to physically take your Bitcoin (they can just take a copy of it) make it their own how you store it is also important.

For valuable secrets that must be stored on paper a Certificate Authority would fold the corresponding paper in half taping each of the open ends close using tamper evident seals.

They would then place each sealed paper into their own opaque tamper evident bags keeping inventory of the bag and seal serial numbers, who was present and then storing the bags and inventory in separate secure locations.

This not only makes it possible to detect what has happened with the stored paper but protects it from water as well. Consideration is also given to what kind of paper and toner is used; for most scenarios one would use archival quality paper and high quality toner. But paper burns and toners are made of organics that can break down in heat so electronic copies are often also kept.

When it comes to those electronic records the choice of what media you use to store those values is important, as many types of media are not reliable for long-term storage. Today I would use the MDISC which effectively engraves the data into a disc that is still readable by modern DVD and BluRay players promising the disc to be readable for 1,000 years.

Even though most data being stored would already be cipher-text one never wants to rely on a single point of failure and for this reason another layer of crypto would typically be used. Commonly this is as simple as using GPG or TrueCrypt with a password to encrypt the data you are going to write to the disc in-turn managing the security of that password carefully.

At this point your down to being concerned with the physical protections your storage facilities offer and ensuring you have long term access to the hardware and software necessary to use the artifacts captured above.