In September 2013, The Serval Project commenced a fifth round of work for the New America Foundation's Open Technology Institute to improve Serval DNA key management to allow Commotion OpenBTS to assign a Serval Identity (SID) to each GSM handset and migrate the identity from node to node to follow the GSM handset. This involves adding multi-key support for node addressing, allowing each node to announce multiple keys, and enabling multiple identities for each node.

• <BOOKMARK:R1>R1. Complete multi-SID support to serval routing engine and network layer.
• <BOOKMARK:R2>R2. Implement servald id enter pin <PIN> which unlocks any SID identities protected by that PIN. If the SID already has a remote route, then the SID is not announced, but if no remote route exists, then the SID is announced as routable to this node. Returns the list of identities unlocked by that pin, and whether each is announced or already has a remote route.
• <BOOKMARK:R3>R3. Implement SID roaming handshake procedure with servald id announce <SID>.
• <BOOKMARK:R4>R4. Implement servald id relinquish pin <PIN|SID>, which releases the specified identities, and removes those identities from the local routing table.
• <BOOKMARK:R5>R5. Add ability to store tags (which could be IEMI/IMSIs) in keyring entries.
• <BOOKMARK:R6>R6. Implement servald id list [<TAG|SID>] that lists all unlocked identities, or only those unlocked identities with a supplied SID or tag (which could be the IEMI/IMSI).
• <BOOKMARK:R7>R7. Extend test suite to cover the above.

The following implementation decisions were made during the course of the contract.

• <BOOKMARK:N1>N1. The R2 and R4 keyring PIN enter and relinquish commands only affect entry PINS not keyring PINs. A running daemon can have at most one keyring PIN, which is set by the command-line option when started and cannot be relinquished while running.
  • the keyring.c code supports many “contexts”, each one with its own keyring PIN;
  • the first “context” is always created, and is for the null (empty) keyring PIN,
  • the commandline.c command-line API only supports a single --keyring-pin=PIN option, which creates a second “context” if used
  • the commandline.c command-line API already supports many --entry-pin=PIN options, however these should not be used for identities that are intended to be dynamically unlocked and locked (see N3)
• <BOOKMARK:N2>N2. The daemon uses one SID as its main identity for its entire lifetime. All other SIDs are treated as secondary identities.
  • the daemon automatically unlocks all PIN-less identities it can find in the keyring on start-up, as well as any whose PINs are supplied on the command line
  • if there are none, the daemon creates a PIN-less one automatically and stores it in the keyring (for re-use in future sessions)
  • the daemon chooses the first unlocked, start-up SID as its main identity
  • the daemon does not allow its main identity to be relinquished (locked)
• <BOOKMARK:N3>N3. The Serval DNA daemon opens its keyring and applies the command-line supplied PINs before starting its routing engine. This has the following consequences:
  • a daemon cannot perform identity hand-over requests while starting up, in order to gain custody of its initial identities
  • thus, if two daemons are started with the same initially-unlocked identities in their keyrings, there will be a routing conflict on those identities;
• <BOOKMARK:N4>N4. Identity hand-over is not performed opportunistically (eg, at regular intervals), so a network merge between subnets which each had the same identity present will produce a routing conflict on that identity.
• <BOOKMARK:N5>N5. The keyring.c code uses the unlocked keyring entries as a positive cache to avoid redundant work:
  • when unlocking with an entry PIN, the code first checks whether there are already any unlocked entries with the same PIN, and if so, does not perform an unlock scan through the keyring file
  • that technique has only ever had a single flaw:
    • if a PIN unlocks no entries, then re-trying the same PIN repeats the unlock scan (ie, there is no negative caching of PIN attempts)
    • functionally this is of no consequence, its only impact is on CPU use and hence potentially on battery life
  • the id relinquish <PIN> command introduces a functional flaw that is revealed by the following sequence of operations:
    • one enter PIN command unlocks two more identities
    • a relinquish SID command then locks one of these identities
    • a subsequent enter PIN command will not re-unlock that identity, because the positive caching will detect that there are still identities bearing that PIN
  • hence, in order for enter PIN to work as expected, ALL identities already unlocked with that PIN must be relinquished first
  • for this reason, if the relinquish SID command is ever used, then for safety every enter PIN command should be immediately preceded by a matching relinquish PIN command

Development commenced in September 2013, prior to the date of contract, and finished in mid October 2013. This report was completed at the start of December 2013, when the contract was submitted for approval as complete.

R1 – multi-SID routing

• commit 73342a9 announces fake links in the routing table to secondary identities (see N2)
• commit 0c1c767 automatically claims the route to any identity with an existing route when all possible routes disappear

R2 – servald id enter pin <PIN>

• commit ae7e120 passes an entry PIN (see N1) to the Serval DNA daemon to unlock an identity in the keyring

R3 – servald id announce <SID>

• commit b8ec568 implements the announce command:
  • if a route to that SID already exists, then sends a challenge/response request to the existing instance of this SID,
  • on receiving the request, the daemon locks the SID and responds
  • on receiving the response, the daemon proceeds to unlock the SID and announce it as routable locally

R4 – servald id relinquish pin <PIN|SID>

• commit ef7351b either:
  • relinquishes (locks) a single identity specified by its SID (see N5), or
  • locks all identities that were unlocked with a given entry PIN (see N2)
• commit d5d5737 renamed the id revoke pin command to id relinquish pin to conform to contract

R5 – keyring entry tags

• commit c3b4d68 adds commands to read, write, and search a new key type for storing name/value pairs (“tags”):
  • the new keyring set tag <SID> <tag> <value> command sets the value of a given tag on a given identity (which must be unlocked by the supplied PIN options)
  • the keyring set did command and the new keyring set tag command both list all DIDs and tags of the affected identity (after applying the modification)
  • the keyring dump command now includes tags in its output
  • the keyring list command does NOT include tags in its output (for backward compatibility reasons)

R6 – servald id list [<tag>|<SID>]

• commit 4e543f7 implements the new id list command:
  • lists identities currently unlocked in the running daemon
  • optionally filters by tag name and value
  • does not include tags or DIDs in its output

R7 – automated test cases

• commit 73342a9 added the tests/routing multiple_ids test case for R1
• commit ae7e120 added the tests/keyring KeyringEntryPinServer test case for R2 (two id enter pin commands)
• commit 0c1c767 added the tests/routing unlock_ids and migrate_id test cases for R3
• commit ef7351b expanded the tests/keyring KeyringEntryPinServer and tests/routing migrate_id test cases for R4 (added id revoke pin commands)
• commit 534b01b added the new tests/keyring DidName test case, to ensure safety prior to refactoring the existing keyring set did command to use the new tag code
• commit 9680b24 added the tests/keyring test case SetTag for R5 (three keyring set tag commands)
• commit 0b404b0 added the tests/keyring test case ListTags for R6 (three id list commands)