Cryptographic authentication of VOEvents

John Swinbank swinbank at transientskp.org
Thu Aug 9 03:48:18 PDT 2012


Dear all,

As I've mentioned on this list in the past, I think it's important to have a means of authenticating the sender of a VOEvent. This is particularly the case as we move towards increasingly automated systems with little scope for humans in the loop. The last thing I want to happen is for us to waste time, resources and credibility by triggering LOFAR observations based on "fake" events, whether maliciously or accidentally generated, and I imagine that the same is true for whichever projects you happen to be involved with.

Of course, there has been some discussion of this in the past, with systems proposed by both Steve Allen (Astron. Nachr. 329, 298–300, 2008) and Bob Denny (http://www.ivoa.net/Documents/latest/VOEventDigiSig.html). As far as I'm aware (and please correct me if I'm wrong!) the only system which is currently in active use is Bob's, and my suspicion is that adoption of even that among the wider community is low.

As LOFAR moves towards an operational mode, my thoughts increasingly turn to what we need to do to guarantee our own security while interoperating as seamlessly as possible with the rest of the community. Given the current situation, adoption of a system similar to the one Bob proposes would seem to meet our immediate needs and provide a relatively low barrier for entry.

Unfortunately, I don't think that Bob's system is completely flawless and, in discussion with him, I've proposed some relatively small changes. I have written up my thoughts in some detail here

  https://github.com/jdswinbank/Comet/blob/master/docs/VOEvent-OpenPGP.rst

and I would appreciate your comments on them.

Do other projects also see this as an area of concern? Does the suggested system seem plausible? What can we do to encourage "buy in" from those of you already producing VOEvents? If we can move towards a consensus, perhaps Bob will be willing to collaborate on updating his note to reflect our latest thinking and it can form the basis for a real community-wide standard.

I'll add a similar disclaimer as to my last mail – I don't for a moment believe that this proposal represents the be-all and end-all of VOEvent authentication schemes. However, while blue-skies discussion is always fun, I'm hoping to arrive at a "good enough" solution that we can start deploying in the real world within months rather than years and with relatively modest investment of developer time.

Cheers,

John


More information about the voevent mailing list