G
GeekMarine1972
Gang;
In Short:
Publicly distributed windows form application that uses .NET 1.1 and
WSE 2.0 SP3. It's built to be multi-user computer friendly.
Publicly accessible Windows Service built on .NET 1.1 and WSE 2.0 SP3.
I intend to use WS-SECURE / WS-SECURE CONVERSATION and WS-ADDRESSING as
well as SSL for the communication.
The challenge is simple. I can happily use User specific
Public-Private key pairs from both the client and the server to encrypt
and sign both the request and the response. I can be certain that the
sender is the user and the responder is my server. However, how can I
be certain that it is MY application that is initiating the webservice
call and the message exchange.
Normally, one would use a private key for the app to use to sign the
messages but there isn't a reliably secure way to store a private key
on a PER APPLICATION, not per user basis. Since public-private key
methodologies are well known, SSL proxying can permit leaking of the
SOAP message structure. The user knows their own private key. The
only choice to ensure that the message originates with our own
application is a private key within the application (which isn't
secure). Yes, the argument can be made that only a small percentage
of the users of the app will have the sophistication to extract the
private key from the app as well as be able to proxy SSL and the like
to be able to generate a private application that consumes our web
service. And our webservice itself will introduce methods to protect
itself from most types of attacks. However, as far as I can determine,
there is no cryptographically strong mechanism for ensuring that the
web service consumer is an application we have distributed.
Is that correct?
Paul the Savant Dude
In Short:
Publicly distributed windows form application that uses .NET 1.1 and
WSE 2.0 SP3. It's built to be multi-user computer friendly.
Publicly accessible Windows Service built on .NET 1.1 and WSE 2.0 SP3.
I intend to use WS-SECURE / WS-SECURE CONVERSATION and WS-ADDRESSING as
well as SSL for the communication.
The challenge is simple. I can happily use User specific
Public-Private key pairs from both the client and the server to encrypt
and sign both the request and the response. I can be certain that the
sender is the user and the responder is my server. However, how can I
be certain that it is MY application that is initiating the webservice
call and the message exchange.
Normally, one would use a private key for the app to use to sign the
messages but there isn't a reliably secure way to store a private key
on a PER APPLICATION, not per user basis. Since public-private key
methodologies are well known, SSL proxying can permit leaking of the
SOAP message structure. The user knows their own private key. The
only choice to ensure that the message originates with our own
application is a private key within the application (which isn't
secure). Yes, the argument can be made that only a small percentage
of the users of the app will have the sophistication to extract the
private key from the app as well as be able to proxy SSL and the like
to be able to generate a private application that consumes our web
service. And our webservice itself will introduce methods to protect
itself from most types of attacks. However, as far as I can determine,
there is no cryptographically strong mechanism for ensuring that the
web service consumer is an application we have distributed.
Is that correct?
Paul the Savant Dude