Securing WebServices call without user login

Question

Hello,
I spawned a thread in the Java Technologies for Web Services forum about different approaches to securing web service interactions.
The security level required is:
- guaranteeing the server's identity (so that the customer does not talk to a phishing server
- guaranteeing the client's identity (so that we don't provide the service for free, and don't leak customer-specific data across customers)
- encrypting the exchanged data
Whichever approach will end up having some local security info stored on the client machine (e.g. client certificate used to guarantee the client machine identity).
Now we have a requirement from some customers that the operator be not required to input any password on the client computer (basically the whole client system is some industrial machine (let's say a steel-knitting machine), and the operator does not knowingly use a computer, but merely a steel-knitting machine with levers and a couple of big plastic square on/off push-buttons).
We also don't have the power or time-to-market to include a hardware authentication mean (e.g. an ID card or dongle).
As far as running our software go, no problem, we will configure the OS to auto-log on startup.
However, we are concerned that the client software, and its client configuration, may be copy-pasted on another machine, and used to sniff our provider's valuable steel-knitting patterns (those data whose transport has to be encrypted).
You may have understood that I am a totally noob as to security aspects. I hope you can help me with the following questions:
- Is there any way to prevent a clone of the client software being copied onto another host?
I guess not; I mean, as far as someone can log onto the machine using the same user as the one the software runs under, he can download the software package, including the configuration and certificates.
- Is there any built-in mechanism that could makes the certificate unreadable or invalid on a cloned machine (e.g., if the certificate includes some terminal-specific info, such as a MAC address)?
- would a check of the client's IP address protect me - I think an attacker can forge its sending IP address, but then he may not receive the reply, is that correct?
Note that we trust our customers to not install more steel-knitters than they bought, so validating the full DNS hostname would protect us. But I'm probably naive to think that we can guarantee against forged domain names.
- It it hopeless? AFAIC, the customer is violating the recommendation to base security on "something he has (conf) plus something he knows (password)". Is it enough of a no-go to pop up the problem to the boss or sales, so that they try to convince the customers?

Answer 1

It's a nogo.Thanks for your valued opinion.
Yes, the more I think about it, the more I'm convinced the requirement is technically unreasonable - although I understand that they want to lower the training and process costs.
(blushing) From a formal point of view (hey, I have a marketing guy to convince first), I haven't found an advisory bulletin from e.g., CERT or OWASP, to support the claim "it's obvious that you can't authenticate a person without a password or a body scan". It must be too obvious...
I'd like to bend their head to authenticating the hardware instead (card/dongle).
What you need here is mutually authenticated SSL with an HSM at the client that requires a password for its use.Yes we are going the mutually authenticated SSL route (subject of the other thread).
As far as using an HSM go, anything more robust that personal cards (which can be a form of HSM) is bound to be too costly for the market.
I'm concerned though about requiring a password: if we force a password scheme onto reluctant customers, I'm convinced we will end up with company-wide passwords shared among all operatives.
Not that different from having a shared (non-password protected) card/dongle that unlocks the machine (e.g. hosts the certificate and compute keys, I don't know too well how an ID card works). The card scheme seems even more secure, as attempts against the card (card lost, stolen, damaged) are more likely to be reported (and trigger revocation of the certificate) than password leaks.
Edited by: jduprez on Sep 14, 2009 3:04 PM