KeyStore and TrustStore

  1. Technically a KeyStore and a TrustStore are of same. They just serve different purposes based on what they contain.
  2. A KeyStore is simply a database or repository or a collection of Certificates or Secret Keys or key pairs. When a KeyStore contains only certificates, you call it a TrustStore.
  3. When you also have Private Keys associated with their corresponding Certificate chain (Key Pair or asymmetric keys), it is called a KeyStore.
  4. Your truststore will be in your JAVA_HOME—> JRE –>lib—> security–> cacerts
  5. ‘cacerts’ is a truststore. A trust store is used to authenticate peers. A keystore is used to authenticate yourself in mutual authentication
  6. cacerts is where Java stores public certificates of root CAs. Java uses cacerts to authenticate the servers.
    Keystore is where Java stores the private keys of the clients so that it can share it to the server when the server requests client authentication.
  7. Keystore is used to store private key and identity certificates that a specific program should present to both parties (server or client) for verification.
    Truststore is used to store certificates from Certified Authorities (CA) that verify the certificate presented by the server in SSL connection.
  8. Mutual authentication requires Keystore and Truststore whereas Server-Client authentication requires truststore to store Certificates from CA.


List the content of your keystore file

keytool -v -list -keystore .keystore

specific alias, you can also specify it in the command

keytool -list -keystore .keystore -alias foo

Importing Certificate to Truststore

keytool -import -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -alias Root -import -file Trustedcaroot.txt

Symmetric Key Encryption (Private key Encryption)

  1. Same key is used between client and server to encryt and decrypt message
  2. Copy of key exist at both ends
  3. First time the copy of key generated should be sent securely to otherside.
  4. Public Key Encryption(Asymmetric Encrytion) is used to get the copy of the symmetric key for the first time
  5. Thoughts may arise if I could share key securely for the first time why don’t I use the same methodology but it is resource-intensive
  6. Advantage is The Encrytion and Decrytion is faster compared to Asymmetric Key Encryption
  7. Disadvantage is Key needs to be transferred for the first time and Key should be stored securely

Asymmetric Key Encryption (Public key Encryption)

  1. Uses Public and Private Key
  2. Encrypted with one key and decrypted with other key. The Client uses public key to Encryt and Server uses private key to decrypt.
  3. Public key would be shared and to recieve encrypted message from client by public key
  4. This similar to Safe(Public Key) and Key(Private Key), When you send data it would be encrypted using public key similar to
    safe which doesnot needs a key to lock. The Private key in server could unlock using the key it holds.

Man-In-Middle-Attack

  1. Man in middle generates his own public key which is available to client
  2. Client used public key provided by man in middle and sends his data
  3. Man in middle decrypts using his private key and makes a genuine request by encryting public key to server
  4. To address this issue certificates were used

Certificates

  1. The main purpose of the digital certificate is to ensure that the public key contained in the certificate belongs to the entity to which the
    certificate was issued, in other words, to verify that a person sending a message is who he or she claims to be, and to then provide the message
    receiver with the means to encode a reply back to the sender.
  2. This certificate could be cross checked and confirmed with certificate authoritiy

Certificate Authoritiy(CA)

  1. A CERTIFICATE AUTHORITY (CA) is a trusted entity that issues digital certificates, which are data files used to cryptographically link
    an entity with a public key. Certificate authorities are a critical part of the internet’s public key infrastructure (PKI) because
    they issue the Secure Sockets Layer (SSL) certificates that web browsers use to authenticate content sent from web servers.
  2. The role of the certificate authority is to bind a public key of Server to a name which could be verified by browser to make sure the response is from genuine server
    Certificate Authority validates the identity of the certificate owner. The role of CA is trust.
  3. Certificates must contain Public Key which could be cross-checked with Certificate Authority(CA)
  4. CA would be mostly big companies like Symantec, google which acts as thirdparty to reassure trust.
  5. Self-Signed Certificate where you uses your own server and client to generate certificate. CA doesnot comes in play in Self-Signed Certificate
    The above method may open door to man in middle attack
  6. Root Certificate is something which you would get when you use Self-Signed Certificate with your custom CA. Root Certificate would be available in
    all client system which access data with server

Communication over HTTPS(HTTP over Secure Socket Layer)

  1. SSL is web servers digital certificate offered by third party.Third party verifies the identity of the web server and its public key
  2. When you make a request to HTTPS website, the sites server sends a public key which is digitally signed certificate by third party or
    Certificate Authority(CA)
  3. On receiving the certificate the browser sends the Certificate with public key to third party to check whether the certificate is valid
  4. After verifiying the certificate the browser creates a 2 symmetric keys, one is kept for browser and other for server. The key is sent by
    encrypting using webservers public key. This encryted symmetric key is sent to server
  5. Web server uses its private key to decrypt. Now the communication happens using shared symetric key.

Typically, an applicant for a digital certificate will generate a key pair consisting of a private key and a public key, along with a certificate signing request (CSR)(Step1). A CSR is an encoded text file that includes the public key and other information that will be included in the certificate (e.g. domain name, organization, email address, etc.). Key pair and CSR generation are usually done on the server or workstation where the certificate will be installed, and the type of information included in the CSR varies depending on the validation level and intended use of the certificate. Unlike the public key, the applicant’s private key is kept secure and should never be shown to the CA (or anyone else).

After generating the CSR, the applicant sends it to a CA(Step2), who independently verifies that the information it contains is correct(Step3) and, if so, digitally signs the certificate with an issuing private key and sends it to the applicant.

When the signed certificate is presented to a third party (such as when that person accesses the certificate holder’s website), the recipient can cryptographically confirm the CA’s digital signature via the CA’s public key. Additionally, the recipient can use the certificate to confirm that signed content was sent by someone in possession of the corresponding private key, and that the information has not been altered since it was signed.