On 24/07/16 05:43, Jacob Wilder 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.
Sorry if I'm being slow here, please help me understand the scenario a bit better. >From what I understand so far: - this is not an 'open' server responding to queries from unknown sources, which would require additional protections; - the querier and responder have been pre-configured to know about each other (by exchanging public keys); - the goal is to sign each exchange of data to authenticate the source of the query/response, which would be useful for audits etc. Did I get that right? >> 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. Sure, that would just be a special case of direct trust vs. trust via the web of trust DB. > 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. As I wrote in a different reply on this thread, having different ways of achieving the same end result is fine. We just need to ensure Pirk is not tied to a particular representation. > 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. Sounds reasonable to me. > 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. I'm still back at the design points at the moment, I guess there are multiple ways to implement a design around the standard formats for signing, key representation, etc. Are you talking about using BouncyCastle OpenPGP APIs? Regards, Tim > — Jacob Wilder > > >> On Jul 23, 2016, at 18:47, Tim Ellison <[email protected]> >> 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 >> >> >
