locked
some questions on crypto api and security RRS feed

  • Question

  • 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.
    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.
    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.
    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.

     

     

    Thank you for your time.

     

    Regards,

    Gurmit

    Monday, August 31, 2009 6:25 AM

Answers

  • Hi

    FQDN (Fully qualified domain name) is what i refered as "Common name" in my reply.

    microsoft.com
    www.microsoft.com
    web1.microsoft.com

    Allo of above domains/subdomains are valid FQDN. A certificate of microsoft.com wil be varified only for microsoft.com and not for www.micorosoft.com

    Ok lets try to understand how Certificate works in browser.

    When browser receive the certificate, It checks the Domain name or IP Address what ever was used to access the url, Against the FQDN with in the certificate. If it dont match then browser show a warning.

    If FQDN with in certificate is microsoft.com and you are accessing the site with www.microsoft.com then brwoser will show a warning.

    So in your case, What will first establish the connection ? Server or Client ?
    If server will initiate the connection and client will send the certificate then server can match the domain/ip which was used to initiate connection against the FQDN in certificate. For example if server connected with microsoft.com then it can see if FQDN of certificate is microsoft.com

    If client will initiate the connection (Most probably)  and client will send the certificate then only option server have is to do a Reverse DNS lookup of connecting IP. And use the rdns FQDN to varify the certificate.

    I will suggest if it is just a client server application and there is no specific requirement to use certificate, just use public/private key based RSA handshake. First create a databse on server for authorized public keys + IPs maping. Then on handshake send a test string (Handshake Challenge) to client encrypted with the public key you have in database for that ip, client have to decrypt and send it back, encrypted with server's public key.

    Regards


    • Marked as answer by Gurmit Teotia Thursday, September 3, 2009 5:00 AM
    Tuesday, September 1, 2009 5:34 PM

All replies

  • Hi

    Let me try to reply you. If i am wrong at some place then any other person can correct me....


    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.

    If you are designing the your own server application and you implemented it in the way that it will receive and process certificate of client then it is fine. But if you are using some predesigne server application then ofcourse you have to follow the rules/protocl of that application server.

    1. 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.
    Certificates are confirmed based on Common Name (Generally Domain name). The receiver (server in your case) varify if sender's (client in your case)  domain match the domain name in certificate. If you are not using domain names then you will have to assign the certificate to IP addresses of clients. But usually for this purpose you have to use public keys, Client send their public key and server can see if public key is changed etc. Ofcourse you will have to keep record of accessed clients and their public keys on server.
    1. 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.
    To create selfsigned certificates check these functions in microsoft crypto api
        CertOpenStore()
        CertCreateSelfSignCertificate()
     
       
    1. 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.
    They will work ok if you send the certificate to server in a supported Encoding.  e.g  X509_ASN_ENCODING


    I hope these hints will help.

    Regards

    Monday, August 31, 2009 11:43 AM
  • Thank you for your response.

    I have query on second question again. I can understand the case where receiver verify valid certificate by comparing IP (given in certificate) to senders IP but how can receiver verify the certificate if it bound to host name (I read on internet that certifcate can't be bound to domain name (microsoft.com) but it can only be bound to FQDN (web1.microsoft.com)? After reading I have understanding the handshake in SSL happen before transfere of any other data. So it raise the the question that how the receiver (in my case server) will verify the certificate if it is bound the host name. How is going to get the host name of sender?

    Thank you for your time.

    Regards,
    Gurmit
    • Marked as answer by Gurmit Teotia Thursday, September 3, 2009 5:00 AM
    • Unmarked as answer by Gurmit Teotia Thursday, September 3, 2009 5:00 AM
    Tuesday, September 1, 2009 12:59 PM
  • Hi

    FQDN (Fully qualified domain name) is what i refered as "Common name" in my reply.

    microsoft.com
    www.microsoft.com
    web1.microsoft.com

    Allo of above domains/subdomains are valid FQDN. A certificate of microsoft.com wil be varified only for microsoft.com and not for www.micorosoft.com

    Ok lets try to understand how Certificate works in browser.

    When browser receive the certificate, It checks the Domain name or IP Address what ever was used to access the url, Against the FQDN with in the certificate. If it dont match then browser show a warning.

    If FQDN with in certificate is microsoft.com and you are accessing the site with www.microsoft.com then brwoser will show a warning.

    So in your case, What will first establish the connection ? Server or Client ?
    If server will initiate the connection and client will send the certificate then server can match the domain/ip which was used to initiate connection against the FQDN in certificate. For example if server connected with microsoft.com then it can see if FQDN of certificate is microsoft.com

    If client will initiate the connection (Most probably)  and client will send the certificate then only option server have is to do a Reverse DNS lookup of connecting IP. And use the rdns FQDN to varify the certificate.

    I will suggest if it is just a client server application and there is no specific requirement to use certificate, just use public/private key based RSA handshake. First create a databse on server for authorized public keys + IPs maping. Then on handshake send a test string (Handshake Challenge) to client encrypted with the public key you have in database for that ip, client have to decrypt and send it back, encrypted with server's public key.

    Regards


    • Marked as answer by Gurmit Teotia Thursday, September 3, 2009 5:00 AM
    Tuesday, September 1, 2009 5:34 PM

  • Thank you very much. My all question are answered in original post but I've one more question.

    In my case software application (client) will send the certificate to connecting device (server) and it(client) will be communicating with hunderds of devices. Client application will be transferring crucial biometric data to devices. Now question was raised that how client application will make sure that it is communicating with inteded biometric device because some other software can also emulate the behavior of biometric device and can steal the data. I don't think we can install a signed certificate (public key+private key) on all devices for their identification (some of our clients will be intersted in using their own signed certificate). Is there any viable solution?

    Regards,
    Gurmit

    Wednesday, September 2, 2009 9:43 AM