[CAP] CAP Security Using Digital Signatures

[matt hoffman]

I did a proof-of-concept implementation of this on a previous DHS system.
Although, as you say, there was no way of verifying it with other providers
or consumers at the time.However, a couple of points that I recall:

a.) The document mentions that the signature element can be a child of
"alert", but unless I'm mistaken it is not specified in the schema.  So
messages containing signatures fail schema validation ... I had to
explicitly add it to the schema.

b.) The signatures are delicate, and tricky:
http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt

Unfortunately I no longer have access to that code, but I'd be happy to help
others if they're looking into it.


- matt

On Wed, Mar 11, 2009 at 11:20 PM, Art Botterell <acb at incident.com> wrote:

> Friends -
>
> We're moving rapidly toward an important threshold in CAP implementations.
>  So far, most CAP-based systems have been self-contained, single
> vendor/implementer arrangements.  But soon we're going to need to "federate"
> CAP traffic among multiple interoperable systems.  And that has important
> implications for security.
>
> Most current systems use a trusted-link/trusted-host mode based on
> encrypted network links and password access control at a central server.
>  That's a familiar Web 1.0 approach and it works fine for "single-hop"
> implementations.  But it has a major drawback: As soon as messages are
> forwarded from one server to another, a security compromise anywhere can
> compromise the authentication and integrity of all CAP messages downstream.
>
> The alternative, of course, is to apply digital signatures to CAP messages
> at their origin, and to verify them at receiving points.  That way, it
> doesn't matter if the links or intervening nodes are secure or not; any
> recipient can verify independently that the message is a) from who it says
> it's from, and b) hasn't been modified in transit.
>
> There's a standard way of doing this for XML, as cited in the CAP
> Specification:
>
> >3.3.2.1 Digital Signatures
> >The alert element of a CAP Alert Message MAY have an Enveloped Signature,
> as described by XML Signature and
> >Syntax Processing [XMLSIG]. Other XML signature mechanisms MUST NOT be
> used in CAP Alert Messages.  Processors
> >MUST NOT reject a CAP Alert Message containing such a signature simply
> because they are not capable of verifying
> >it; they MUST continue processing and MAY inform the user of their failure
> to validate the signature.
>
> But I'm not aware of anyone that's implemented it yet... partly because it
> hasn't been necessary in stand-alone systems, and partly because it involves
> a type of programming a lot of folks haven't had occasion to explore yet.
>
> But ultimately, it's going to be essential for interoperability.  So I'd be
> interested in hearing, has anyone implemented XMLSIG on CAP yet?  And would
> anyone be interested in doing some interoperability experiments?  The
> standard is there, the technology is there (in Java and a number of other
> languages) and I see the requirement bearing down on us quickly.
>
> What say?
>
> - Art
>
>
> _______________________________________________
> This list is for public discussion of the Common Alerting Protocol.  This
> list is NOT part of the formal record of the OASIS Emergency Management TC.
>  Comments for the OASIS record should be posted using the form at
> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
> CAP-list mailing list
> CAP-list at lists.incident.com
> http://lists.incident.com/mailman/listinfo/cap-list
>
> This list is not for announcements, advertising or advocacy of any
> particular program or product other than the CAP itself.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.incident.com/pipermail/cap-list/attachments/20090312/8bc9f488/attachment.html>