Re: Using a 'secret' SSL client certificate from Mozilla
On Sep 7, 6:55 am, Konstantin Andreev wrote: > On 08/28/10 02:36, Michael Smith wrote: > > > 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). > > Hello, Michael. > > Would this work ? > > 1) hardcode the cert. and the priv. key into your app. binary (maybe > hidden/masked/...) > > 2) at run time, import them into NSS softoken as ephemeral (session) > objects. Konstantin, That looks like pretty much what I want to do - but I've been unable to figure out how to do part (2) there. Many of the NSS APIs are not terribly well documented. Any pointers to sample code or even just to the relevant functions would be very helpful. Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On Sep 3, 11:53 am, Nelson B Bolyard wrote: > On 2010-08-30 11:04 PDT, Michael Smith wrote: > > > On Aug 28, 10:08 am, Nelson Bolyard > > wrote: > >> What is the real underlying objective of this? > >> Is it to authenticate the individual user of the product to the servers? > >> Is it to ensure that the client applications of the network service are > >> genuinely those made by your "partner", and not some other client that > >> has been made by some third party who reverse engineered your protocol? > >> (e.g. as AOL used to try to ensure that only genuine AOL clients > >> accessed the AOL Instant Messenger servers?) > > Yes, the intent is to ensure that the client application is a > > "legitimate" application, and to prevent others (even if the _user_ is > > appropriately authenticated with username/password) from accessing the > > servers. > > [snip] > > > Any advice you can give would be greatly appreciated! > > The "attack" against which you're trying to guard is that someone reverse > engineers your protocols and creates a substitute client that talks to > your servers. Presumably, someone does that by reverse engineering your > client. Anyone who can do that can find the private key and the client > certificate, which will be embedded in your client binary somewhere, > and aren't very big, and use them in their substitute client, also. > So, embedding a key and cert in your binary really doesn't offer much > protection, IMO. > > In some sense, the problem is that the info that the attacker must replicate > is too small and too easily replicated, if it is merely a > key and cert, or for that matter, if it is merely the static content > of an executable program file. I know of a company (:-) whose products > had a protocol whereby the server asked the client "give me the contents > of your memory starting at this address for this many bytes", which was > an address in the code portion of the program, as a means of authenticating > the client program. The idea was that this made the entire program file the > data that must be kept, no tiny subset of it was enough to fool the server. > The attackers simply shipped a copy of the original program along with > their replacement, and their replacement program answered those requests by > reading the original program file to find the answers. > > If you assume that the attacker has full access to every bit of data that > the server shares with the client, then trying to distinguish between a > "legitimate" client and a replacement becomes a game of testing the > limits to which the attacker is willing to go to emulate the original. > But you can go quite far in that direction, producing results that require > quite a bit of emulation to replicate. It requires demanding results that > depend on quite a bit of dynamic data, and not merely depending on static > data that can be gotten from the original program file. And it can all be > overcome with enough reverse engineering. > Nelson, Absolutely! I understand the limitations of this approach, and why it's ultimately a waste of time and effort for all involved. I'm unfortunately not in a position to replace the mechanism in use - though we can do anything we wanted to our client, the servers we're talking to are run by another company, and aren't going to be changed. It's a silly design, but something I'm stuck with. I'm not enough of an expert in this field to design a 'good' system myself, but I'm capable of recognising something that is badly designed. My question was, therefore, simply how to implement this using NSS, rather than anything else - your description of what approaches could be taken is interesting (and would be helpful if I were trying to design something myself). Thanks, Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On 2010-08-30 11:04 PDT, Michael Smith wrote: > On Aug 28, 10:08 am, Nelson Bolyard > wrote: >> What is the real underlying objective of this? >> Is it to authenticate the individual user of the product to the servers? >> Is it to ensure that the client applications of the network service are >> genuinely those made by your "partner", and not some other client that >> has been made by some third party who reverse engineered your protocol? >> (e.g. as AOL used to try to ensure that only genuine AOL clients >> accessed the AOL Instant Messenger servers?) > Yes, the intent is to ensure that the client application is a > "legitimate" application, and to prevent others (even if the _user_ is > appropriately authenticated with username/password) from accessing the > servers. [snip] > Any advice you can give would be greatly appreciated! The "attack" against which you're trying to guard is that someone reverse engineers your protocols and creates a substitute client that talks to your servers. Presumably, someone does that by reverse engineering your client. Anyone who can do that can find the private key and the client certificate, which will be embedded in your client binary somewhere, and aren't very big, and use them in their substitute client, also. So, embedding a key and cert in your binary really doesn't offer much protection, IMO. In some sense, the problem is that the info that the attacker must replicate is too small and too easily replicated, if it is merely a key and cert, or for that matter, if it is merely the static content of an executable program file. I know of a company (:-) whose products had a protocol whereby the server asked the client "give me the contents of your memory starting at this address for this many bytes", which was an address in the code portion of the program, as a means of authenticating the client program. The idea was that this made the entire program file the data that must be kept, no tiny subset of it was enough to fool the server. The attackers simply shipped a copy of the original program along with their replacement, and their replacement program answered those requests by reading the original program file to find the answers. If you assume that the attacker has full access to every bit of data that the server shares with the client, then trying to distinguish between a "legitimate" client and a replacement becomes a game of testing the limits to which the attacker is willing to go to emulate the original. But you can go quite far in that direction, producing results that require quite a bit of emulation to replicate. It requires demanding results that depend on quite a bit of dynamic data, and not merely depending on static data that can be gotten from the original program file. And it can all be overcome with enough reverse engineering. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On Aug 28, 10:08 am, Nelson Bolyard wrote: > On 2010-08-27 16:48 PDT, Michael Smith wrote: > > > 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. > > What is the real underlying objective of this? > > Is it to authenticate the individual user of the product to the servers? > > Is it to ensure that the client applications of the network service are > genuinely those made by your "partner", and not some other client that > has been made by some third party who reverse engineered your protocol? > (e.g. as AOL used to try to ensure that only genuine AOL clients > accessed the AOL Instant Messenger servers?) Sorry for not being clearer. Yes, the intent is to ensure that the client application is a "legitimate" application, and to prevent others (even if the _user_ is appropriately authenticated with username/password) from accessing the servers. i.e. Standard HTTP authentication is used to authenticate the user, and an SSL client certificate is used to authenticate the application binary. This is why I want to keep the certificate "secret" from the user; it logically belongs to the application, rather than the more typical use of client authentication, where the private key logically belongs to the _user_. > > Is it something else? > > The use of public key certificates may not be the best way to accomplish > your objective, or even an appropriate way at all, but we cannot determine > that until we know what that objective is. I'm pretty unconvinced that this is a sensible way to accomplish the real objective, but unfortunately I've been given no choice - the partner insists on this being the only acceptable way to access their servers. Any advice you can give would be greatly appreciated! Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On 2010-08-27 16:48 PDT, Michael Smith wrote: > 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. What is the real underlying objective of this? Is it to authenticate the individual user of the product to the servers? Is it to ensure that the client applications of the network service are genuinely those made by your "partner", and not some other client that has been made by some third party who reverse engineered your protocol? (e.g. as AOL used to try to ensure that only genuine AOL clients accessed the AOL Instant Messenger servers?) Is it something else? The use of public key certificates may not be the best way to accomplish your objective, or even an appropriate way at all, but we cannot determine that until we know what that objective is. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On Aug 27, 4:30 pm, John Dennis 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
Re: Using a 'secret' SSL client certificate from Mozilla
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 Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
