Andy, I had considered using symmetric signatures but I think that while it is simpler in the pairwise case it would lead to significant complexity if we reach a point where one responder is servicing queries for multiple queriers. In that case we would need to use different symmetric signature keys for each partner-pair.
As heavy as OpenPGP is we get the benefits of a standardized, language independent key and signature format for which software already exists. I like OpenPGP's clearsign format for this situation because it avoids having to package a signature file with the payload whenever it is being sent from one participant to another. The code I've prototyped already works with trusting multiple public keys—property serialization.openPGPPublicKeyRing will point to an OpenPGP ASCII armored public key ring which can contain as many public keys as desired. If you attempt to verify an object and the signing key (for the valid signature) is in that file it will be approved. Basically, we get the multi-party case for free. Would we rather specify a config parameter to determine whether we are using > PGP (or something else)? My original plan was to have a property which switches between "All files must be signed" and "All files must be unsigned" because it makes for really simple code paths. But when I wrote the original email I thought about it and realized that it'd be really annoying if you ran a system where you accepted unsigned files and someone sends you a signed one. You don't care about the signature but now you have to change your configuration (or hand-unwrap the base64-encoded binary object). That's why I suggested "serialization.requireSignedInput" as the property so the option is between "All files must be signed" and "Unsigned files are just as OK as signed files". — Jacob WIlder On Sat, Jul 23, 2016 at 1:48 PM, Andy LoPresto <[email protected]> wrote: > PGP is a robust (but sometimes complicated) system for this purpose. It > certainly makes sense to offer it, but it seems that using an HMAC/SHA-256 > for example would provide a sufficient level of trust over the serialized > data. If my understanding is correct, it’s not necessary to fully resolve > the identity of the data provider to a unique source, rather simply to > enforce that the data was provided by an entity at a certain trust level. > It’s a trade-off between managing a high number of key pairs and accepting > that a one or more shared secrets is distributed in the ecosystem. > > > Andy LoPresto > [email protected] > *[email protected] <[email protected]>* > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Jul 23, 2016, at 5:41 AM, Ellison Anne Williams < > [email protected]> wrote: > > Sounds good Jacob - this will be a great addition to Pirk. > > I think that the the specified properties/options seem reasonable. The only > factor to consider down the line is that one instantiation of a Responder > could be servicing multiple queries at one time -- if they are all being > signed, then you could have multiple keys. I don't think that we need to > necessarily tackle architecting for that case now (as our Responders > currently work on a single query at at time), but it's something to think > about as we expand the Responders to multi-query (at some point in the > future). > > One question -- Are we sure that we want to tie it to PGP? > > "By default, all InputStreams used to read data will be checked to see if > they start with the line "-----BEGIN PGP SIGNED MESSAGE-----" > > Would we rather specify a config parameter to determine whether we are > using PGP (or something else)? > > I am in favor of having an initial single-key, PGP implementation and then > expanding from there. > > Thoughts? > > On Fri, Jul 22, 2016 at 11:43 PM, Jacob Wilder < > [email protected]> wrote: > > Given that deserialization attacks are a ripe attack surface > <https://www.owasp.org/index.php/Deserialization_of_untrusted_data> it's a > good idea to make it possible to authenticate serialized objects whenever > possible. In the case of Pirk—where systems which hold sensitive data will > be deserializing objects received from other entities—offering users the > option to sign/verify objects before loading them is valuable. If our users > were not dealing with sensitive information of some sort, they wouldn't be > using Pirk. > > I have written some code that uses BouncyCastle to OpenPGP clearsign base64 > encoded Java objects. I'm going to see how cleanly I can integrate it with > Tim's new Serialization code so that it's automatically available to > anything that uses the serialization tools. > > Where things get complicated is in how to expose it to users. Below is my > current thinking. I'd appreciate any feedback. > > By default, all InputStreams used to read data will be checked to see if > they start with the line "-----BEGIN PGP SIGNED MESSAGE-----". If it does, > we'll pull the PGP public keyring from a path specified by property > serialization.openPGPPublicKeyRing and verify the signature. Failed > signature verifications result in an exit. > > Property serialization.requireSignedInput will reject any input that is not > signed with a valid signature. > Property serialization.signOutgoingObjects will sign all outgoing > Serialized Java objects. > Properties serialization.openPGPPrivateKey, > serialization.openPGPPrivateKeyPassword, > and serialization.openPGPPublicKeyRing will indicate the location of the > private key, the password used to decrypt it, and the location of the > public key ring respectively. > > > I had considered using SignedObjects but decided to give OpenPGP a shot > because it's easier to hand-verify signatures or integrate verification of > signed data into automated data flow (say, between two distinct entities > sharing data using Pirk). > > > — > Jacob WIlder > > >
