cally important and fundamentally challenging. Previous work explored how such “stepping-stone” relationships may be inferred in the network, 20 and a similar approach—attributing each causal link hop-by-hop—could be employed with our architecture as well. However, unambiguously establishing such causality is not possible at the network layer alone and will ultimately require both host support and, inevitably, manual investigation. While we have a vision for how such host services should be structured, it represents future work beyond the scope of this article.

architecture

While these requirements appear challenging, there is a well-known cryptographic tool—a group signature11— that unties this particular Gordian knot. Here, we briefly review the properties of group signatures, describing their basic application to forensic packet attribution and the design issues resulting from this architecture.

Group signatures. A group signature provides the property that if a member of a group signs a message, anyone can verify that the signature was created by a group member but cannot determine which one, without the cooperation of a privileged third party, the group manager.

We describe group signatures using the formalized model of Bellare et al., 5 as well as a definitional extension due to Boneh et al. 8 Specifically, a group-signature scheme assumes a group manager and a group of n unprivileged members, denoted 1, 2, . . . , n. The group manager has a secret key msk, each group member i ε { 1, . . . , n} has its own secret signing key sk[i], and there is a single public signature-verification key pk.

The group manager uses a KeyGen operation to create pk, msk, sk, distributing them appropriately. Subsequently, if a group member i uses its secret key sk[i] to Sign a message m and gets back a signature σ, anyone with access to the global signature-ver-ification key pk can Verify that (m, σ) is a valid message-signature pair under the secret key of a group member. The group manager can use msk to recover the identity i of the signer using the Open operation.

The two principal security properties for group signature schemes— full-anonymity and full-traceability—imply other properties, including unforgeability, exculpability, and framing-re-sistance. 5 A group signature scheme is CCA-fully anonymous if a set of colluding members cannot learn information about the signers’ identity i, even when adversaries are allowed to Open the signatures of all the messages besides the target message-signature pair. A group-signature scheme is fully traceable if a set of colluding members cannot create a valid message-signature pair (m, σ) that the group manager cannot trace back to one of the colluding parties; that is, either Verify(pk, m, σ) fails, meaning the signature is invalid, or Open(msk, m, σ) returns the identity of one of the colluding members.

Basic packet attribution. We apply group signatures to our problem in the following way: Each machine is a member of some group and provided with a secret signing key. Exactly how groups are constructed, and who is authorized to open resulting signatures, is very much a policy issue, but one pragmatic approach is that each computer manufacturer defines a group across the set of machines it sells. Being manufacturer-centered is particularly appealing because it sidesteps the key distribution problem, as manufacturers now commonly include trusted platform modules that encode unique cryptographic information in each of their machines. Moreover, a tamper-resistant implementation is useful for preventing theft of a machine’s signing key. This approach would also imply the manufacturer would act as group manager in any investigation, execute Open under subpoena, or escrow its msk (or shares thereof) to third parties.

Given a secret signing key, each
machine uses it to sign the packets it
sends. This signature covers all non-
variant protocol fields and payload
data. The name of the group and the
per-packet signature are included in a
special packet header field that is part
of the network layer. Any recipient can
examine the header, using Verify
to validate that a packet was correctly
signed by a member of the associated
group (and hence could be authenti-
cated by the group manager). The ver-
ify step does not require protected key
material and, by virtue of fate sharing,
need not be part of the trusted comput-
ing base.