Re: questions on security API and security

Thank you Laszlo. I'm clear on first point.

Regarding second question. We'll give the option to end user to either
use their own signed certificate or use our default signed
certificate. We have to live with this option, we can't force (only
recommend) to user to use signed certificate. Please suggest If there
is any better way than this which does not involve finacial decision.
I was thinking of creating our company CA certificate (reason it is we
who are putting everything on device) and sign the other certificate
but in this case we have to distribute only one signed certificate
(signed by our CA certificate) with all distribution of software;
which is also a risk.

Laszlo, I'd like to ask another question in same thread. In my case
client application will be communicating with hunderds of devices; how
can client application make sure that it is communicating with
intended device? One option is to have cetificate (plus private key)
in devices as well. Now if some client is intersted in using signed
certificate I'm not sure if we should place same signed certificate on
all devices or each device should have seperate signed certificate. I
see problem in each both appraoch. In former it is security and in
later it financial. Is there any other better approach?

I'm sorry in case of any wierd question; I'm new to both crypto API
and SSL security.

Thank you for your time.

Regards,
Gurmit

On Sep 1, 8:34 pm, lelteto <lelt...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I think you have some misunderstanding.

1. SLL doesn't care about WHERE the client connection originated from. There
is no such information in certificates. (Although you could put that info
into the cert, SSL will not care about it.) IF you want to restrict
connections to certain IP addresses, you would have to create your own
authentication: on the server create a list of allowed IP addresses then
check in your code that a connection's source address is one of them. In that
case don't bother with certs and SSL.

2. There is no point using "self-signed" certificates (except in testing)..
ANYBODY can create such self-signed certs so you have no way verifying if the
cert (and, hence, client connection) is coming from a legitimate place or
from a hacker.

Laszlo Elteto
SafeNet, Inc.



"Gurmit Teotia" wrote:
Hello Laszlo,

Thank you for your response.

I think I was not clear on 2nd question and 3rd question-

In second question I was having the query on how receiver will verify
the certificate that it is coming from correct computer. e.g. if
certificate is bound to IP then receiver will compare the IP of sender
with IP given in certificate but I'm not sure how receiver will verify
the certificate if it is bound to host name. As per my understanding
no other data is send in SSL before handshake and during handshake
receiver only know the IP address not the host name of sender. So
question was how receiver (in my case server) will identify if
certificate is coming from correct source?

In third question I was having the query on how to generate the self
signed certificate because in some cases client might not be having
the signed certificate. But I believe I got the answer for it. There
are some function in crypto API which can be used to generated self-
signed certificate.

Thank you for your time.

Regards,
Gurmit

On Aug 31, 8:23 pm, lelteto <lelt...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
See some responses in-line below.

Laszlo Elteto
SafeNet, Inc.

"Gurmit Teotia" wrote:
Hello All,

I’m first time using Crypto API in my application. I’ve some
questions; I’d appreciate if I can get some help on them.

1. In normal usage it is server that send certificate to client and
then they start encryption and decryption process but in my case it is
client that has certificate not the server. Is that a valid case where
client send the certificate not the server and security frameworks
support such usages? In my case application software, act as client,
will communicate with multiple devices, acting as server.

[LE] It depends on the security reason. In your case the (server) devices
want to make sure that the client is authenticated before granting access to
the server. Certificate-based authentication of clients is much better than
simple password authentication, so you are doing the right thing.

2.How a party (in my case server) will decide that the certificate is
coming from correct client. I’m aware of concept (but not crystal
clear) that certificates are bind to either IP address or domain
name.

[LE] The point of certificate based authentication is not just the
certificate. The client (your sw acting as) also needs the PRIVATE KEY
corresponding to the certificate. The way you authenticate:
- cleint sends the cert to server
- server validates the certificate (via the certificate chain up to a
trusted root cert)
- server generates a RANDOM chellenge and sends it to the client
- client SIGNS the random challenge with its private key and sends the
signature to the server
- server extracts the public key from the certificate and verifies the
response
- if the signature is valid, the client is authenticated

3. I’ll be installing a default certificate during installation,
incase user does not have his own signed certificate. How can I
generate that certificate? I know of “makecert” utility but I believe
it is not redistributable.

[LE] the process starts with generating a private+public key pair. You save
the private key (that's what will be used for the client authentication - see
above) and use the public key to generate a certificate request. This cert
request is then sent to a CA (certificate Authority) who signs it,
essentially attesting that the information in it (client data) is valid. The
generated certificate then sent back to the client.

4. On client side I’ll be using Windows Crypto API but device will be
using Open SSL framework. Theoretically both should work without any
problem but just wondering if incompatibilities were discovered in
past.

[LE] This should work fine. The only issue you will encounter is ENDIANNESS.
OpenSSL uses big endian data while CAPI uses little endian. So you will need
to byte-swap the signature before sending it to the server.

Thank you for your time.

Regards,
Gurmit- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

.

Relevant Pages

  • Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle
    ... SSL only validates you are talking to a SSL certified server; ... They can simply edit the URL the client program ... can be done by using a X.509 certificate on both ends, ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: LDP client authentication fails
    ... I got the LDP working with LDAP server under server client authentication ... I did not installed the certificate in pfx format .. ... Client cert auth won't work without that. ...
    (microsoft.public.windows.server.active_directory)
  • Re: SSL & Man In the Middle Attack
    ... >> it possible for the middle man to intercept all messages from server to me ... > server sends client a signed message along with a digital certificate. ... > client generates a random secret key, ...
    (comp.security.misc)
  • Re: activesync issue
    ... On the SBS 2003 Server open the Server Management console. ... On the "Web Server Certificate" page, choose to create a new Web server ... Install the new certificate which created in above step on mobile device: ... Access to browse the Exchange Server 2003 client after you install ...
    (microsoft.public.windows.server.sbs)
  • [Full-disclosure] VMSA-2006-0010 - SSL sessions not authenticated by VC Clients
    ... X.509 certificate when creating an SSL session, ... Both the client and server need certificates from a mutually-trusted ... VirtualCenter 2.0.1 Patch 1 and VirtualCenter 1.4.1 Patch ...
    (Full-Disclosure)
Quantcast