SIFA - Tutorials Index

<< Home

Tutorial: Bottom-Up Evaluation

This tutorial provides a small example of a bottom-up security evaluation performed using the Secure Information Flow Analyser. In a tool as general as SIFA, it is difficult to prescribe a single technique that covers all evaluations, so here I will just outline the process that I use when analysing a hardware device. There should be enough information provided here to follow the step-by-step process for the running example, assuming some general familiarity with the basic editing operations covered in the user-guide.

Note: these steps do not consider probabilistic profiling, as this is still being developed.

  1. Import VHDL into SIFA. Rename the top-level "Entities" view to give the device a sensible name. [more]
  2. If power circuitry is to be ignored, identify the net-lists used for the power circuitry (VCC/GND), and disable these components. It is probably a good idea to document this as a major assumption. [more]
  3. In some VHDL models, SIFA will generate default component definitions more than once (under different architectures). Disable any repeated definitions so that they do not interfere with the analysis. A good idea might be to cut and paste the definitions into a single unified library.
  4. Create an instance of the imported VHDL, and add the source and sink ports. The type of the instance is the 'sensible' name that was chosen in Step 1. This instance is probably best placed in the top-level "Architecture" view. [more]
  5. Optional: Create a custom component library, and disable the VHDL defaults. Alternatively, the VHDL defaults may be edited. The component definitions form a critical part of the assumptions made when evaluating a device, and should be carefully documented. [more]
  6. Run an all-paths analysis for zero points of failure over this model. [more]
  7. Create a new abstract view from the root.
  8. Find the key ports and components along the paths and add them to the abstract model, including the source and sink ports. Give the ports exactly the same names as they appear in the analysis (fully-qualified). If there are no paths found, this may indicate a either a bug in the model, or an ideal model. Care should be taken to ensure which is occurring.
  9. Connect the abstract components as per the connectivity of the all-paths analysis results. Use as much detail as necessary to convincingly convey the key parts of the architecture relevant to the security argument.
  10. Perform a point-point consistency analysis comparing the abstract and VHDL models, for zero points of failure. This will confirm the correctness of the abstract model. Since it was derived from the all-paths analysis, there should be no problems with the consistency.
  11. Perform a point-point consistency analysis comparing the abstract and VHDL models, for one point of failure.
  12. If there are results from this analysis (most likely), create a new sub-view of the abstract model to contain the connectivity resulting from a single fault. For each connection in the results of the point-point consistency analysis, add this connectivity (by creating a `faulty' abstract component) to the new view.
  13. As each connection is acknowledged, its possible impact on the security of the device should be noted. It is probably a good idea to distinguish (using views) between faults that are critical and faults that are not.
  14. Repeat from Step 10 with greater limits on the number of points-of-failure until the resultant connectivity becomes too unlikely to be plausible.
  15. Optional: In the preferences window, enable "Search.ConsiderFullReachability" and re-run the consistency analyses to make sure there is nothing in the abstract models that does not apply to the security argument but is a deceptive representation of the VHDL all-the-same.