+1 When you've integrated with the new serialization code, it would be great if you could go ahead and submit a pull request so that folks can see and comment on the implementation.
On Sun, Jul 24, 2016 at 12:43 AM, Jacob Wilder < jacobwilder.opensou...@gmail.com> wrote: > > Agreed. Either we figure out the identity of the sender via > > establishing a secure communication channel, and trust them to send a > > well-defined message; or have a more open communication channel and look > > to verify each message and its sender more thoroughly. > I think that the best model to implement for Pirk is the latter: provide > people the tools to authenticate individual messages independent of the > communications channel. I’m envisioning cases where Pirk is being used on > systems that don’t have a direct connection to the internet—perhaps one of > the responders is behind a data diode or zealous firewall. Providing > end-to-end authentication using public keys allows for users of Pirk to > more effortlessly assure their data. Adding additional partners doesn’t > require sharing and installing a new symmetric secret for that pairwise > connection, just sharing existing, non-sensitive public keys. > > > Doesn't that require you to know all your senders a priori? Probably > > better to include the public key in a certificate so Pirk can define the > > accepted CAs. > I don’t see this as a problem. I’d expect the participants to be able to > exchange public keys (after all, running wideskies (and other PIR > algorithms) is pretty computationally expensive—the participants are > probably already talking to each other quite a bit to arrange to use Pirk). > This isn’t unlike providing someone with your SSH public key to enable you > to log in. > In this model users can simply ignore the traditional PKI model > traditionally associated with X.509 (and OpenPGP’s web of trust). All they > need to do is share public keys and add them to the keyring their wideskies > instance trusts. > > Using OpenPGP’s format means that tons of finished tools exist to parse > keys and signatures. In a system where a response or query object must pass > through something like a diode or guard machine the guard can verify the > signature without running any software specific to Pirk. It’s simpler to > tell someone to set up their guard machine to check the return value of a > precooked gpg2 command than to tell them to check a keyczar signature. > > Summary of my overall claims: > 1) It is worthwhile to provide end-to-end authentication of data for this > application. > 2) Asymmetric signatures are preferable to symmetric signatures for this > application because it lets users verify the authenticity of incoming data > in additional places without needing access to the very symmetric key which > would enable forgeries. > 3) The base64 encoding + OpenPGP clearsign is a nice way to encapsulate > the payload and a signature in the same file in a well understood format. > > > And I totally agree with banishing Java object serialization. > Also, I’m a big fan of libraries like NaCL and keyczar. I just don’t think > they’re the right solution here. > > — > Jacob Wilder > > > > On Jul 23, 2016, at 18:47, Tim Ellison <t.p.elli...@gmail.com> wrote: > > > > Ah the trust model discussion, that wasn't parked for long ;-) > > > > On 23/07/16 04:43, Jacob Wilder 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. > > > > Yep, and of course it is broader than serialization issues whenever you > > open a communication channel with an untrusted agent. > > > > Java serialization is notorious. I'd suggest we drop it as soon as a > > reasonable alternative is put in place. There are more robust options. > > > >> 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. > > > > Agreed. Either we figure out the identity of the sender via > > establishing a secure communication channel, and trust them to send a > > well-defined message; or have a more open communication channel and look > > to verify each message and its sender more thoroughly. > > > >> 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. > > > > I guess you are describing your prototype here. In general, the > > serialized form would dictate how the signature and supporting files are > > exchanged. > > > >> 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. > > > > Doesn't that require you to know all your senders a priori? Probably > > better to include the public key in a certificate so Pirk can define the > > accepted CAs. > > > >> 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). > > > > Using the JDK APIs can produce standard secure hashes, key/cert, etc > > representations usable by common tools, though I'd recommend using > > something like Keyczar to get a good implementation of common crypto > > patterns. > > > > Regards, > > Tim > > > > > >
