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.