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] 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 >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
