FAQ
What we propose is paradoxical, and surprises many at first. Here are some questions people have asked us, and our responses:
- What if malware refuses to get swapped out?
- Do you need to know how much RAM a device has?
- Do you need to know how much free RAM a device has?
- What if malware infects the kernel or your detection routine?
- What if malware fudges the timing results, or forges the right checksums?
- What happens if the latency variance is substantial?
- What do you do if you detect an infection?
- What if the malware hides in secondary storage?
- Do you quarantine detected malware?
- How can one ever avoid zero-day attacks?
- Why not simply reboot instead?
- How long does the scanning take?
- Does this only work for smartphones?
- Is it an application?
- Have you implemented it?
- Are you selling this product?
Q: What it malware refuses to get swapped out?
That is not a problem. We do not assume that it will agree to be swapped out with all the legitimate processes. In fact, we assume that it will try to remain active in RAM, in order to attempt to modify the results of the scan.
But to be active, a malware agent has to take up space in RAM. Either empty space, or part of the the space of our routine. We overwrite the entire space that should be free with a pseudo-random string. If malware does not want to be overwritten, it can selectively block writes, of course. It can even write those values elsewhere – like secondary storage – in order for the checksum to be possible to calculate later on.
But accessing secondary storage is slower than accessing RAM. Our routine will accentuate the differences by creating access patterns that are fast in RAM, but slow for flash and other storage technologies. By timing the computation of the checksum, cheating can be detected. The external verifier in charge of determining whether a given client is infected would know.
Q: Do you need to know how much RAM a device has?
Yes. But that will be determined when the device registers, mostly automatically and from the serial number. The consumer would never have to worry.
In cases where extra RAM is added, or RAM is simply replaced, the new hardware can be reported when the device is first started up. (To avoid that the device is infected and this report is not made, one can run the scan right before installing the new hardware.)
Q: Do you need to know how much free RAM a device has?
Yes. But that is easy. The amount of free RAM is the difference between the amount of RAM and the size of the detection routine (and kernel, if that is not swapped out). We know the amount of available RAM. We know the size of the detection routine. The remainder should be free. If it is not, that is because of malware.
Q: What if malware infects the kernel or your detection routine?
It does not really matter. It is not possible to do that without changing the contents of RAM. The external verifier knows what these contents should be – since it knows the binary of the detection routine and the kernel, and it sets the seed used to compute the pseudo-random string used to fill RAM. Therefore, the external verifier would notice if the checksum is wrong. See the argument above.
Q: What if malware fudges the timing results, or forges the right checksums?
You cannot fudge the timing results. The client does not submit “it took me half a second”. It receives the seeds and keys from the external verifier, computes intensively for a while, and submits the responses. The timing results are simply the time it took between receiving seeds and keys and returning the result.
You can also not fudge the checksum. It is computed as a non-linear accumulator of the RAM contents, which consist of the detection routine and the pseudo-random string. You cannot pre-compute this value, since the keys and seeds are needed.
Q: What happens if the latency variance is substantial?
That is bad, since that would make a clean device appear infected.
We have developed an array to tricks to minimize latency variance, involving use of SIM cards, tethered devices, and base stations. Common for all: low variance.
Note that the latency does not matter much, since that is predictable, it is only latency variance we need to be concerned with.
Q: What do you do if you detect an infection?
That is a policy decision. You probably want to attempt cleaning the device. You certainly want to flag it, so that it can only transact in a limited manner. You communicate to the user – maybe simply by turning off data service.
Q: What if the malware hides in secondary storage?
Yes, that is certainly possible. We first determine that there is no active malware. Assume that this has been done. Now, there are two principal approaches that can be taken.
1. You can start scanning secondary storage for malware, whether using a whitelisting or blacklisting approach. Since we know that there is no active malware at this stage, scanning is not done in an adversarial setting, and we can trust the results.
2. In some settings, you may not care whether there is dormant malware. You know now that there is no active malware, so now it is safe to perform sensitive transactions. Set up an SSL connection; cast a vote; perform a payment.
In other words, it depends on who runs the scan, and what they care most about. Removing malware or just transacting securely?
Q: Do you quarantine detected malware?
We do not. We detect infection, that’s all. But there are other companies that are good at quarantining and cleaning. We are focusing on what we know best: detecting malware. The others do not guarantee detection. But we do.
Q: How can one ever avoid zero-day attacks?
A zero-day attack is a threat that is not yet known of by anti-virus vendors. But it does not matter to us whether the threat is known or not. Does it try to be active? If so, it takes up space, and we detect it. If no, then we would detect the modification of legitimate applications when we whitelist secondary storage.
Q: Why not simply reboot instead?
Rebooting is slow, we can do things much faster. But the important difference is that bootloaders can be infected, which would avoid detection, but if our routine is infected, this will be detected.
Q: Can’t malware simply overwrite the scanner?
Yes, that is possible. Or simply disable it. But if the external verifier tries to initiate scans, and nothing happens, that is a sign of problem in itself. Yes, it could mean that the device is turned off, and therefore cannot respond. Any device that generates network activity and refuses to perform a scan for some period of time will be considered corrupted.
Q: How long does the scanning take?
This depends on many factors. The amount of RAM, the speed of the processor, and the speed of the connection between the device and the external verifier. For 256 MB RAM and a 600MHz ARM processor - a typical smartphone – we are talking between half a second and 4-5 seconds. That is for the scanning of RAM only; the whitelisting or blacklisting of flash is on top of that.
Q: Does this only work for smartphones?
No. Any device with a processor and RAM. Phones, e-readers, game consoles, netbooks, laptops, desktops … car infotainment systems. We focus on devices with network connections, but in principle, our scan works for modern cameras, microwave overs … you name it.
No. It needs root privileges. (Like most other anti-virus software.)
Yes. We have a proof-of-concept implementation for an Android developer’s platform. It can be implemented for any device, but this involves rewriting device drivers, or at least having access to their specs.
Q: Are you selling this product?
We are not a consumer-facing company, and you cannot download our software for your phone. We offer licenses to our intellectual property.