Short Notes on Public Key Infrastructure–Part 1

The focal point of a PKI setup is the Certificate Authority, CA. The CA works as the Management hub for the digital certificates.

Considering that load on the CAs, some setup use an additional server called the Registration Authority (RA). The RA takes off some of the load from the CA by handling the verification of the data submitted to CA before the issue of the digital certificates. The RA acts as an interface between the user and the CA. The RA is generally found in the hierarchical model where the work load of the CA may need to be offloaded.

One of the main requirements of PKI is to be able to store public keys and certificates at a location that can be accessed by public. The public and the private key is created at the same time using the same predefined algorithm.

A digital certificate is a collection of predefined information related to the a component of the PKI setup, called the Public Key. The digital certificates use the X.509 standards. The X.509 standards allows the association between the users Distinguished name and the public key. The Distinguished Name is provided by the Naming authority and is used as a unique number while creating the certificate. A X.509 certificate generally contains the following:

  1. Serial Number:
  2. Subject: Name of the organization or the person identified.
  3. Signature Algorithm
  4. Issuer:
  5. Valid From:
  6. Valid To:
  7. Public Key
  8. Thumbprint Algorithm
  9. Thumbprint

Certificate Policy is the set if rules that indicate how exactly the certificate may be used. The CP is a plain text document that is assigned a unique object id so that anyone can reference it. A certificate can be used under multiple policies. For example, a digital certificate can be sued for:

  1. Access control
  2. Setting up of trusted connection
  3. System sign on
  4. Digitally sign documents.

Certificate Practice Statements explain how to implement the Certificate Policy. It describes how the CA plans to manage the certs it issues. All CAs should have CPS.

Digital certificates are revoked when the information they contain are no longer valid or trusted. The most common reason for the revocation of the digital certificates is the compromise of the private key. Note that certificate Revocation is different from Certificate expiration. A certificate can be revoked by the CA by confirming with the certificate owner or the PKI administrator.

Certificate Revocation List: X.509 standards require that a CRL gets published. CRLs contain the revocation status of =certificates that the CA manage. CRLs can be:

  1. Simple CRL
  2. Delta CRL

OCSP- Online Certificate Status Protocol: Returns the following details about a certificate queried:

  1. The cert status (good/revoked/unknown)
  2. The last update on the cert status
  3. The next time the status will be updated.
  4. The time when the response is sent.

….

Advertisements

Web Application Threat Modeling – Its Hot and Buzzing!!

Recently I flunked an interview wherein the interviewer was asking lots of questions around threat models. While I will not be putting any of those questions here, I did do my “after the horse bolted” type of post mortem and have come up with a list of questions that anyone who works with design of web application should be aware of.

First the obvious one Smile What is Threat Modeling?

Well It’s a hot buzzword these days in the world of Information technology security. Threat modeling is a structured approach to analyze your web application design and identify threats against your system. Hmnn of…you said THREAT? Threat model is very useful in identifying security issues related to design early in the application development lifecycle and thus makes mitigating those issues less costly as compared to identifying in the, say Verification phase.

So what is a Threat? Threat is a possible harm that can be caused to an Asset (anything of importance that needs protection; from a web application perspective it may be user passwords, keys, financial information, etc.)

Where and when do you start Threat Modeling? A good point to start threat modeling is just after you are done with the functional and technical design document of your application. Having said that it is never to late for you to start, if not in the current release, this may help in the next.

What are the general steps involved in Threat Modeling?

The threat modeling process should ideally start with a brain storming session to answer the following questions (by not means an exhaustive list..so think think think):

  1. What is asset to the system?
  2. Who are the end users?
  3. Where will you deploy the application? Is this an intranet application or will be accessible over internet?
  4. What would attract a malicious user to your system?
  5. What security mechanisms do you have in place?
  6. How many point of failures does this application have? One??? Run back to the drawing board…

While doing the threat model of an application (or anything) think like an attacker who is trying to sabotage your app. Find ways on subverting your system’s weaknesses. This will help you create an Attack Tree (a What??????)

Once you have identified the threats, what’s next? Remember risk can never be erased fully, you can only Transfer/Accept/Ignore the risk. And that’s exactly what you do once you have identified the threats. A good threat model will have ALL the identified threats reviewed and updated as Ignore/Accept/Transfer.

—–)0(—————–)0(—————–)0(—————–)0(————