Hi Kyle,
You seem to understand my situation. Unfortunately, I think using a
hardware based TPM is out, given the heterogeneous nature of our
customer's network (and the costs involved). I'd really like to have
a machine based, password protected X509 certificate solution, as this
would be relatively easy to install as well (e.g. one of the customers
largest agents has stores across the UK, and getting to each one to
install hardware based tokens would be very costly -not to mention the
cost of the tokens themselves. If they could install a passphrase
protected certificate on the machine, they could log in remotely in to
do it). Security wise, we're happy enough to retain a
username/password scheme to identify what actual user is at the
machine. Restricting users to certain machines will cut the main
avenue for fraud in the business that currently exists (as mentioned
before this is phishing for usernames and passwords through social
engineering).
Nothing I've heard thus far has made me think that this is an
inherently bad idea, I suppose what I need is help in accomplishing it
(and preferably accomplish it in Mozilla - our application is quite
AJAXy and the Javascript speedup in Firefox 3.1 is a godsend)
Denis
On Sat, Jan 31, 2009 at 2:50 AM, Kyle Hamilton <aerow...@gmail.com> wrote:
> This is very much akin to needing to authenticate that a machine used
> to perform the transaction submission was, indeed, configured by the
> information technology staff. This is a very important concept that
> cannot be discounted or ignored.
>
> Essentially, what you need is a two-stage authentication process:
>
> 1) Authenticate that the machine connecting to your TLS server is
> acceptable (via unique identification of the machine -- the function
> of a per-machine X.509 certificate that the OP wants), then
> 2) identify the user on the machine to verify that he's really
> authorized to perform the task that he's trying to do.
>
> I would recommend the following approach:
>
> 1) Per-machine keys/certificates, embedded into the machine's TPM or a
> hardware dongle that cannot be removed from the machine, issued by a
> particular CA name (referred to here as "MachineCA")
> 2) Per-user keys/certificates, stored normally, and issued by any other CA
> name.
>
> On the TLS server side, you would first send a ClientAuthRequest with
> the acceptable CA name list only including "MachineCA".
> If the client cannot authenticate, terminate the connection.
> If the client authentication violates policy (working "after hours",
> for example), terminate the connection. (I would be VERY careful
> about this one, though, since there are any number of reasons why
> someone would want/need to work after hours.)
> If the client can authenticate, then immediately send another
> ClientAuthRequest with an empty CA name list such that the user could
> select the client certificate to use.
> If the client sends the MachineCA certificate again, fail the connection.
> Otherwise, proceed.
>
> If you want to reduce the chance that the user will send the MachineCA
> certificate twice in a row (thus failing the connection), compile a
> list of CA names that the clients use, and add them all to the second
> ClientAuthRequest (without mentioning MachineCA in that list).
>
> (This is permitted by TLS, as well as SSL all the way back to SSLv2.)
>
> People, remember: not every situation fits into your narrowly-defined
> Holy Writ worldview. I've been trying to get this through your
> collective heads for a while now. This is a situation that does not,
> and the fact that you're trying to reinforce the dominant paradigm
> without realizing that the standards allow for a LOT more leeway than
> you're giving them credit for is only a testament to your
> closed-minded dogmatic "expertise".
>
> -Kyle H
>
> On Fri, Jan 30, 2009 at 1:36 AM, Denis McCarthy
> <dmccar...@annadaletech.com> wrote:
>> Hello Arshad,
>> Thanks for the email. I suppose the one thing I'd like to stress again
>> is that we wish to authenticate a machine, not a user. Many users may
>> log in to a certain machine (via a username and password that we would
>> issue). What we need to do on our system is to ensure that the user
>> logging is valid to log in on that particular computer ('terminal' as
>> our customer calls them). The terminal itself is connected to the
>> company that the user works for in our database.
>> Regards
>> Denis
>>
>> On Fri, Jan 30, 2009 at 12:08 AM, Arshad Noor
>> <arshad.n...@strongauth.com> wrote:
>>> Denis,
>>>
>>> You have already made the appropriate leap to this conclusion.
>>> I was going to suggest that there is something atypical about
>>> your application architecture if you're relying on authentication
>>> of the *machine* without the use of a hardware token - such as a
>>> smartcard, TPM chip, etc.
>>>
>>> What you want are FIPS 140-2 Level 2 (or above) certified crypto
>>> tokens that generate keys on-board and store the certificate of
>>> the user on the token (in addition to the browser). The private
>>> key, however, never leaves the token, thus ensuring its security.
>>>
>>> Once your customers are issued these tokens with their personal
>>> certificates, they can use it on any PC they desire (assuming
>>> that the PC has been configured with the appropriate CA cert-
>>> chain).
>>>
>>> If you absolutely need to rely on authenticating the PC, then
>>> the only option you have is the TPM chip, because it is built
>>> with the chip on the motherboard by the manufacturer.
>>>
>>> As an aside, StrongAuth, Inc., the company I represent has been
>>> in the business of architecting, building & operating some of the
>>> largest closed-PKIs in the world for enterprises, with the use of
>>> crypto-tokens. Most recently, we built a PKI for a bio-technology
>>> company that embedded secure processors with digital certificates
>>> into three different parts of their product, so that they may
>>> strongly authenticate to each other before being used. This was
>>> designed to deter counterfeiters from cloning the consumable part
>>> of their product. The device is currently awaiting FDA approval
>>> before coming to market.
>>>
>>> Feel free to get in touch with us, if we can be of any help to you.
>>>
>>> Arshad Noor
>>> StrongAuth, Inc.
>>>
>>> Denis McCarthy wrote:
>>>>
>>>> Thanks for the suggestion David. Unfortunately we are not connecting
>>>> to an active directory domain - our application has to go out over the
>>>> internet. I did a bit of fiddling with the certificates snap ins, but
>>>> Microsoft only makes certificates installed in the user account
>>>> available to IE. One other thing I've been mulling over - is it
>>>> possible to get a cheap piece of hardware (i.e. a dongle of some sort)
>>>> that you can put an X509 certificate on? If so, could anyone point me
>>>> in the direction of a company that provides such a product?
>>>> Regards
>>>> Denis
>>>
>>> --
>>> dev-tech-crypto mailing list
>>> dev-tech-crypto@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>>
>>
>>
>>
>> --
>> Annadale Technologies Limited
>> --
>> dev-tech-crypto mailing list
>> dev-tech-crypto@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
Annadale Technologies Limited
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
