> 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 > >
