The following simple study can give you a flavor of what it is like to do an architectural risk analysis (see Chapter 5). Even though this example is beyond contrived, working through it (especially if you follow the process described in this book) is an excellent pedagogical tool. Try doing this exercise with a group. Drink some wine. And don’t cheat!
This case study presents a real-world architecture and description of a software system. Please read through the description, look at the architecture diagram, and then answer the questions given. Thinking about how the system works (and how your understanding differs from someone else’s) will frequently result in finding ways to break it.
The Smurfs are developing a new biometric authentication device to keep non-Smurfs out of the Smurfland network. The biometric device is being dubbed the SmurfScanner by Papa Smurf. The SmurfScanner is a hardware device that scans a user’s skin color for blueness. Since only Smurfs have that unique Saturday morning cartoon blue color, if the device can successfully identify the unique blue, then this will do for making a determination as to whether or not a person really is a Smurf (or at least we make this assumption for the purpose of this exercise, be it based in actual fact or not).
The SmurfScanner is attached to a PC running MicroSmurf Windoze XP via serial port. Along with an all-blue user manual and a blue SmurfWare coffee mug, the SmurfScanner comes with software that allows it to act as the login screen manager in Windoze. To even get to the login screen, a user’s Smurfness has to be established by the SmurfScanner. Once calibrated by the manager application, the SmurfScanner returns whether or not a user is sufficiently blue. The software architecture of this system is represented by the diagram in Figure C-1. Each box represents a separate process running on either the PC or the hardware of the SmurfScanner device.
SmurfScanner Crypto Helper: Since actual authentication traffic between the scanner and the software has to be encrypted and integrity has to be ensured, the software package provides an API for making encrypted calls, such as IsUserASmurf()
, to the SmurfScanner. The caller gets to decide whether to use the proprietary but extensively tested (by two Smurf crypto experts) Smurfcrypto library or the equally solid Microsmurf Windoze implementation of crypto. The Helper exists in both the PC and the SmurfScanner hardware to facilitate two-way integrity and privacy.
SmurfScanner Common Command Layer: The SmurfScanner formats higher-level API calls into a format that the serial driver can understand, be they encrypted or not.
SmurfScanner Manager: Since this application is rarely used, crypto was deemed unnecessary. Instead, the Smurfs hard-coded a hash of Smurfette’s body weight in milligrams in both the SmurfScanner and the Embedded I/O Manager so that the SmurfScanner’s Embedded I/O Manager would recognize that the privileged commands were coming from only the SmurfScanner Manager application. The Manager application appends this hash to every command sent to the scanner. The Smurfs chose this secret method because Smurfette’s body weight is a well-known fact within the entire Smurf community but not known at all outside of it. The Manager application is used to set up the scanner’s calibration and to run diagnostics in case it is malfunctioning. The scanner must be calibrated for local light conditions with a sample Smurf before use. The Manager is also used to initialize the Helper apps on both the PC and the scanner with secrets to allow the integrity and privacy functionality to work. The secrets are a hash of the system clock.
SmurfScanner Embedded I/O Manager: This app sorts encrypted versus unencrypted commands and forwards them to either the Helper or directly to the Logic Layer. Commands are sent directly to the Logic Layer when the I/O Manager recognizes the Smurfette body weight shared secret hash.
SmurfScanner Logic Layer: This layer takes the hardware measurement of a user’s blueness and compares it to the calibrated value and returns a yes or no, thus performing authentication on a Smurf. The Logic Layer also does other things like calibrate the scanner based on data received from the Manager app, track usage, and run diagnostics.
SmurfScanner Business Application: It is critical to understand the business context in order to estimate impact (in such a way as to answer the “Who cares?” question). In this case, the SmurfScanner is being used to protect SmurfTunes from use by non-Smurfs. SmurfTunes is set up to deliver Saturday morning cartoon theme songs to SmurfPod personal digital listening devices.
Tons of extra credit for performing this exercise by following the risk analysis process from Chapter 5.
DO NOT CHEAT. Work out answers before you look at the ones I provide.
Some of the questions have more correct answers than the ones listed here.
Given your answers from the SmurfScanner Risk Assessment, draw a new software architecture diagram for the SmurfScanner system that mitigates the risk. Also, list the other things you could do to secure the application.
The various processes should only accept commands from the other processes explicitly shown in the diagram. Each piece of software should be signed by SmurfWare, and this signature should be used to verify the caller.
SmurfScanner Manager communications should be encrypted.
There should be only one solid crypto implementation in the solution.
The first time the device is used, the password for the Manager-level functions should be set by the Manager app. The password should be used from that point on. The hard-coded shared secret should be eliminated.
The Crypto Helper should be seeded with something more entropic, such as mouse movements, not the system clock.
A sample fixed architecture is depicted in Figure C-2.
[1] This exercise was developed by Michal Propieszalski and has been used at Cigital to teach architectural risk analysis for several years.
3.147.85.221