TATER: Tamper Analysis via Transient Electromagnetic Response

TATER is a tamper analysis system that monitors deterministic computer programs and detects unauthorized modifications. The TATER system functions when placed in close proximity to the target proessor. It works by capturing and comparing electromagnetic emanations from a target processor by using a correlation algorithm. The value of this project is that it can verify code integrity without requiring modification to the target software or hardware.

Background
In some situations, it may be impractical to physically modify a system in order to monitor it. Whether due to financial matters or system dependencies, this may worsen the severity of existing vulnerabilities since successful exploitation of these vulnerabilities may not be identified for days, or even years. The goal of TATER is to verify code integrity without requiring modification to the target system. It works in close proximity to the target processor by monitoring electromagnetic signals emanating from the processor and correlating them with an established baseline from code that is "known" to be good.

Specifications
Our product should not require modification of the target system. It should be sensitive enough to detect relatively small changes in the boot code but flexible enough to allow multiple configurations. It should be possible to update the monitoring system to continue correctly characterizing the boot code if it is updated. Analysis should take no longer than a couple of minutes.

Alternatives and Decisions
We considered using an FPGA to process signals, but ultimately decided that the best choice for research and development purposes would be to use Linux on a laptop. This is a diagram of our setup design:



Our strategy is to design an antenna to pick up electromagnetic signals emanating from a processor and analyze peaks in the frequency compared with an established baseline to identify modifications in the boot code. Various statistical analysis techniques may be of use in pursuing this goal.

Antenna Design
Recent developments have shown that our antenna design will be centered around the important data of our signal rather than all of it, with a bandwidth ranging from 1-250MHz. This range of frequencies is difficult to obtain in a cost effective and minimum volume mindset, which translates to what will likely be a homemade antenna.

Previous Antenna Design Considerations
{| width="100%" These antennas were considered along the course of our project, and are being left up to demonstrate the learning process.
 * - align="left" style="vertical-align: top;"

Hardware Design
The hardware setup is in the process of being finalized. When it is complete, the antenna will sit inside a fitted shielding box and send signals through an ADC to a Linux computer.

Algorithm Design
We are planning to use cross correlation to align our waveform sequences. We then normalize the data using the highest and lowest values and correlate the capture sequence with an established baseline. This allows us to compare the locations of peaks over time and produce a percentage representing the similarity between the sequences.

At this point, we have created a proof-of-concept program that correctly recognizes when code has been modified by inserting or deleting instructions. Repeated captures over the same sequence consistently produce a correlation of >99%. We are only able to detect single assembly-level instruction changes if they are dissimilar - say an ADD and a MOV, for instance. Replacement of similar instructions with each other, even to the level of an ADD and a MUL, are not detectable. The difference between them is indistinguishable from the normal <1% variation between captures caused by external noise and imprecise equipment.

Data Pre-processing
At this point, the only pre-processing that is done is aligning the signals to start at the first peak. This was previously done by filtering out all values below a certain level until the first high value occured, recognized as significantly about the average of the first several thousand signals. We are transitioning to using cross correlation to align the sequences, since the sampling rate has been decreased and it is no longer possible to match the locations of the first peaks as closely as necessary.

Implementation and Testing
A probe and oscilloscope are used to capture electromagnetic signals emanating from the target processor. Captures from the same sequence of code produce a correlation of >99%, which is excellent. If instructions are added or removed, then this correlation falls significantly and the algorithm can detect these changes. Currently, we are able to detect single assembly-level instruction changes only if the instructions being modified are significantly different - such as replacing and ADD with a MOV. Changing an ADD to a much more similar SUB, on the other hand, is not significant enough for our current algorithm to register the difference. Complications such as background noise picked up along with the legitimate code emissions account for the <1% variation between captures on the same sequence of code, which makes it much harder to identify tiny changes such as replacing an ADD with a SUB as mentioned. Fortunately, most modifications would require multiple instruction changes in order to accomplish the intended purpose.

Test Results
To the left is an example of signals captured by an oscilloscope. To the right is a graph showing the difference between specific instructions and a NOP instruction.

Meeting Minutes












































Presentations and Monthly Status Reports