On Aug 27, 4:30 pm, John Dennis <jden...@redhat.com> wrote: > On 08/27/2010 06:36 PM, Michael Smith wrote: > > > > > Hi all, > > > In our (mozilla/xulrunner-based) application, we're trying to set up a > > secure connection to a server that requires a client certificate. > > > Rather than the normal case of a client certificate belonging to the > > user, and just added to the certificate store, we want to have a > > certificate that nominally belongs to the application, and is secret > > from the user (strange, but that's what I'm stuck with). > > > The specific requirements are that we not store it unencrypted in the > > filesystem - and simply setting a password on the key db isn't an > > option, as that would interfere with the _user's_ use of the key db > > for any of their certificates, and that it must not be available in > > the UI (so we want to somehow hide it from the 'View Certificates' UI > > - or at least not be exportable from there). > > > Can anyone suggest an approach to implementing this? > > System services (e.g. daemons) have a very similar requirement for > accessing their security information and being able to operate > unattended. The usual solution for system services is to create a > "system" user (typically a uid less 1024, but that varies by OS). The > security information is placed in a file only that user can read. Upon > start up the process will switch it's effective uid to that uid. However > if your application is a normal user process running under the uid of > the user that won't work. It works in the case of a system service > because those processes start with root privileges and can "drop > privileges" to the daemon uid after they've begun executing. > > Very much akin to what I described above are the requirements for > storing a host certificate for machine authentication when joining a > domain. But once again the storage of that cert is protected by root > level privileges. > > Another possible approach would be akin to what Cyrus SASL saslauthd > does. saslauthd is a tiny root daemon process who purpose is to access > authentication information on behalf of an unprivileged process. The > unprivileged process sends a request to saslauthd which is running with > root privileges and requests it perform an authentication on it's > behalf. In fact the basic concept is not all that different from RADIUS. > > If your application is a normal user application running under the uid > of the user who started and you have no way to install and start a > system daemon then I can't think of a mechanism that couldn't be > compromised and/or wouldn't require user intervention. Anybody else have > better ideas?
John, Thanks for your description. Our application (Songbird) is a desktop client app - think of it as a mozilla-based web browser, for the purposes of this discussion. I have a fairly solid working understanding of how system daemons typically do this sort of thing - and like you said, this doesn't really apply here, since this is an unprivileged user application. We're not really looking for a "couldn't be compromised" solutions - this is a requirement from a company we're partnering with, not our idea, and they basically just want it to not be "simple" (for some value of that) to compromise. So: serialising it to disk without some sort of encryption isn't ok, and exposing it in exportable form in the browser UI isn't ok. Something that is "difficult to hack" whilst not truly secure would be fine. I understand the limitations of this approach (and were it up to me, I would not 'secure' this stuff using such a mechanism). Ultimately, we're trying to hide from the actual human user something that must be readable by the user's process. The intended approach would be to "hide" the certificate/key inside our application binary (probably obfuscated in some way) - the bit that I'm looking for some help with is how to hook this into the mozilla HTTPS layer _without_ exposing it to the certificate UI. Thanks, Mike Smith Songbird -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
