CanaryTail

CLI client

Web client

Introduction

CanaryTail was developed to standardize criteria in warrant canaries as a means of simplifying the process of creating, distributing, monitoring, and administrating warrant canaries.

░ Warrant canary

"Warrant canary" is a colloquial term for a regularly published statement that a service provider has not received legal process that it would be prohibited from saying it had received, such as a National Security Letter (NSL).

░ The Problem

Warrant canaries introduce several issues as have been witnessed from organizations that employed or maintained them improperly. This standard seeks to resolve those issues through a proper standardized model of generation, administration, and distribution, with variance allowed only inside the boundaries of a defined protocol. Those issues are:

▖ Confusion attributed to non-standardized language
▞ Loss of access leading to misinterpretation
▘ Imperfect generation, maintenance, and distribution
▙ Inability to automate the monitoring
▚ Reliance on centralized generation and maintenance
▛ Reliance on centralized distribution

░ Scalability

Thanks in no small part due to the valiant efforts of CanaryWatch (a collaborative project between Calyx, EFF, Freedom of the Press Foundation, NYU Law, and the Berkman Center), adoption of warrant canaries — at least in the beginning — was explosive, gaining much traction on the internet as a viable means to combat unconstitutional and unethical intervention from governments through the use of NSLs, gag orders, and their international equivalents.

¹ Search frequency for the term “Warrant canary” since 2007

While adoption had continued to increase over time, the inability to automate verification and maintenance of those canaries has proven too troublesome for many parties to continue employing them, and without a standardized framework and language for the canaries themselves, not only has it made automation impossible, but misinterpretation is frequently common. Upon discontinuation of the original CanaryWatch project, the Electronic Frontier Foundation was quoted as saying "the fact that canaries are non-standard makes it difficult to automatically monitor them for changes or takedowns".

Standard

To resolve these issues, CanaryTail standardizes the very language of the canaries themselves through codification, whereas one can construct a human and machine readable warrant canary that can be programmatically verified. To consider what language should be standardized, we need to first define the purpose of the canary and under what conditions it is considered as failed.

In general, canaries are designed to fail when:

▖ Warrants have been issued for searching, seizing, or monitoring data
▞ NSLs, gag orders, or other court orders have been given to hide, conceal, or otherwise withhold information from the public
▘ Backdoors have been planted to spy on and trap users
▙ Raids have been conducted on hardware and operating premises
▚ Integrity of access keys and leadership of a company is no longer sound or trustworthy

In the case of gag orders, some make it unlawful to reveal the exact number of occurrences of requests for data for example, but do allow for an organization to reveal a broad range (e.g. “anywhere from 0 to 1,000”). This combined with a general statement that there has never been a request, one may deduce whether or not a request has in fact been made, and to a certain degree, how many times.

░ Codification

Codes used in the canary are loosely named after their threat and response category:

CODE		DESCRIPTION
war		Warrants
gag		Gag orders
subp		Subpoenas
trap		Trap and trace orders
cease		Court order to cease operations
duress		Coercion, blackmail, or otherwise operating under duress
raid		Raids with high confidence nothing containing useful data was seized
seize		Raids with low confidence nothing containing useful data was seized
xcred		Compromised credentials
xopers		Compromised operations

░ Trust levels

Construction of the canary is done as JSON array with multiple options for verification based on trust needs.

LEVEL		DESCRIPTION
▖ LOW		The canary can be authenticated to the original source by providing the DOMAIN it will be served at. This is a less secure method of authenticity as anyone with publishing access to the domain can modify the canary.
▞ MEDIUM		Authentication of the canary is done via ECDSA ( Curve25519 ) cryptographic signature of the JSON array by the public key provided inside as the variable PUBKEY.
▘HIGH		The ECDSA ( Curve25519 ) PUBKEY can be a split-key created by n-of-p in order to ensure multiple parties consent to updates of the canary.

░ Fields

FIELDS		DESCRIPTION
domain		Specifies the web address (if any) tied to the entity. This is used for simplistic TLS/SSL certificate verification of authenticity as well.
pubkey		Specifies the public key (if any) tied to the entity. This is used for signing the canary itself to prove authenticity.
panickey		Specifies the public key (if any) that can trip the canary simply by being signed by it. This is used when the party wishes to end the canary for whatever reason.
version		Specifies the protocol version (different protocols may behave differently or contain different codes).
release		Specifies when the canary was signed.
expiry		Specifies when the canary should expire and no longer be considered valid or safe.
freshness		Specifies a recent block hash from the bitcoin blockchain. This is used to provide evidence that the canary was not signed before said block was mined.
codes		Specifies a string of the codes that apply to this canary, ordered alphabetically. Missing codes indicate tripped canary.

░ Structure

    {
        "canary": {
            "claims": {
                "domain": "cryptanalys.is",
                "pubkey": "Y4PsjneDjxckrgibojs38VDWFBTyvlVtTQR3Z9RTRw0=",
                "panickey": "",
                "version": "0.1",
                "release": "2020-09-30T19:17:40+09:00",
                "expiry": "2030-09-30T19:17:40+09:00",
                "freshness": "00000000000000000008b4177c1302331aa546635d65306d35c97a8b9bb3461d",
                "codes": { "cease", "duress", "gag", "raid", "seize", "subp", "trap", "war", "xcred", "xopers" }
            },
            "signatures":{
                "signed_domain": "Eajg00cYjeP1Tt//6moo2eMpfHnrd8HZnOqY1XcawoqgwBrF4pIQ984kxN1uLQQHaKfStoWJTM5MKhR5aujTBA==",
                "signed_pubkey": "S=j6gRr8H0toY5EqT4kTMoKPILHdh95tqaueZ1M0KWOQFMH1mwnefQXN/oBcQjYa2uapcaArp=gj81x/oJwfnTB4",
                "signed_panickey": "I8MRN5YcTrnhMEaHKwkp5A0wnogqqjerM9B/T/uLpegjao14StQfP8B2t1=oYfJ6T1HZxmaQQOcd=aoH0KXWFj4u",
                "signed_version": "HamapANgBeFR/oM2oXahS58H8P1W4qJnjfZkB=ErKK0ocLQTueqI56jujx0QcQ=41oMOMgadYTnwwpr9YHtft/1T",
                "signed_release": "wJa2xfcSTPFk1BYMd5Tpgo/HB=rK48QWjQXHr8OQImct1ea5R9gjTtufu0Y/oaqHh0KqoZ6jwMLn4p=1EMNeAnoa",
                "signed_expiry": "=ngLZnT1eojPMF0MKaq8TaTQ=waO/1YrIRc4jNHBg0xja1or5J9fKBtqM46QQpwHfcueWYdEm25oAS/pohktXu8H",
                "signed_freshness": "YoT=h1Bnw5KMWRH9muLQSF8HaYc5kJZ/QpXcEBjpfg1/uoa4w=qnxTaNTtHoPQ2daKj8gjMIOMf0Art6e1oe0r4q",
                "signed_codes": "1J4joZKaQYorhqcOQkSwK8T1qt8=mog25IXr1e6LHF0Ba0/nu/HguQMf59dxoYMAMjfPaTpHRatWpETNnc4Bewj="
            }
        }
    }

Using the canary above, one may programmatically determine that the owner of the canary is confident that:

▖ they have not received warrants or gag orders of any kind
▞ they have not been asked to spy on their customers or users or install backdoors
▘ their premises were not raided with any noteworthy seizures
▙ their operational integrity and credentials are intact
▚ they decided to update their key to a new one for whatever reason, and will be signing all future canaries with that new key