Trojan Steals Credit Card Numbers

It’s only a proof of concept, but it’s scary nonetheless. It’s a Trojan for Android phones that looks for credit-card numbers, either typed or spoken, and relays them back to its controller.

Software released for Android devices has to request permissions for each system function it accesses—with apps commonly requesting access to the network, phone call functionality, internal and external storage devices, and miscellaneous hardware functions such as the backlight, LED, or microphone. These requests are grouped into categories and presented to the user at the point of installation—helping to minimise the chance of a Trojan slipping by.

Soundminer takes a novel approach to these restrictions, by only requesting access to ‘Phone calls,’ to read phone state and identity, ‘Your personal information,’ to read contact data, and ‘Hardware controls’ to record audio—none of which will ring alarm bells if the app is marketed as a voice recording tool.

Research paper here. YouTube demo. Another blog post. Research paper; section 7.2 describes some defenses, but I’m not really impressed by any of them.

Tags: academic papers, Android, cell phones, credit cards, cybercrime, Google, malware

Posted on January 29, 2011 at 7:45 AM • 43 Comments

Comments

Henning Makholm • January 29, 2011 7:59 AM

“Hardwars controls” does sound like an awfully broad permission to give.

Henning Makholm • January 29, 2011 8:00 AM

HardwarE too, even.

go2null • January 29, 2011 8:34 AM

I’d also venture to say that most users just tap pass the permission screen without reading. (Just like the EULA screens.)

This is partially due to the users not understanding (or caring) about the permissions, poorly wriiten apps that ask for unneeded permissions, and no way to revoke individual permissions.

Bruce Stephens • January 29, 2011 9:02 AM

All of the permissions are overly broad (IMHO). And your options are to accept or reject all of them (rejecting meaning you don’t get the application).

OTOH, if the permissions were more specific you’d likely end up with terms that nobody would read.

And phones get installed with apps (sometimes hard to remove) from the manufacturer and (potentially) the network.

Nidhi • January 29, 2011 9:31 AM

Network communication? Really..why would an app need that?
I am wondering how much testing do these cellphone companies so as to allow the existence of such apps and approve of the level of authorization asked for?

Phone calls, Data, Personal Information are broadly used terms and do not tell enough of the kind of information they require access to.

My question is why do they need it all and why are the app stores simply letting them.

The need to stay in the “apps” competition, companies are approving applications as long as app developers use the APIs provided and “follow” the T&C.

By simply clicking on the T&C does not guarantee that the app is not rogue. End users do not have that level of expertise to question everything they download.Coz their “trust” connection is with the service provider or a cellphone company.

These thoughts lead me to question, who to be held responsible?
Since its the user whose information is in danger, it must be it.

This makes user awareness extremely important.

Clive Robinson • January 29, 2011 10:21 AM

Nice use of “designed into the OS” side channels as a covert channel to communicate between the two apps.

And this is the real problem, some activities on these side channels you would expect from the app and somebody “black box watching” for security excursions would not of necesity see them.

For a simplistic example we know mechanical keys have to be “debounced” due to contact noise thus you expect to see momentary random fluctuation on the rising and falling edges. However if the switch is very noisy or pressed slowly the length of the fluctuation could easily exceed the software timer used to “debounc” thus it would not be unexpected to see the appropriate action to be repeated at the output of an action etc. Thus it would be easily possible for an application to add an encoded bit at the end of an action involving a key press to say control the volume. The OS convieniently passes this “bit” onto all other applications registered to control the volume.

Such covert channels in OS’s have been known for many years examples being using a printer or changing the access time file etc etc.

I wrote a brief bit about their near thirty year history and GJ Simmons who discovered them on this blog back in september along with some links ( http://www.schneier.com/blog/archives/2010/09/successful_atta.html#c458633 )

I also noted that they where nearly impossible to design out of a general purpose “efficient” computing platform such as a PC or in this case a Smart Phone.

Eric Vetillard • January 29, 2011 4:08 PM

In additoin to malware, this paper outlines privacy issues with Android. The “Read contact data” permission gives access to call history, meaning that it considers that knowing who I actually call is the same as knowing who I know. Similarly, the “Record audio” permission makes no difference between recording in plain sight (while the application is running and visible) or in stealth mode (when it runs in the background, and I don’t care about whether it just records phone conversations or also my direct conversations.

Also, the side channel part looks way too complicated to be realistic. In real life, it is likely that attackers will hide their malware in an application that legitimately access Internet. Why bother using such a complex scheme?

Nick P • January 29, 2011 5:09 PM

The problem is that the permissions are too coarse-grained. They need to be fine-grained, specific and easy to revoke. The capability approach works very well for mobile apps designed for Android. OK Lab’s OKL4 kernel uses capabilities and a tiny kernel-space TCB to enforce security with quite a bit of assurance. They’ve already ported Android to run on top of it, with critical apps running directly on the microkernel. I think we need to break it up further, building a true microkernel OS that uses capabilities to enforce app restrictions. I don’t see any chance of preventing POLA-related attacks without going this route.

Fortunately, we already have products on the market that can do this. Just need the other parts of the OS ported to it. I also want a trusted path for the phone and a key or key combination that gives me an unspoofable way to launch or switch apps. That’s very critical. I won’t put a password manager on my phone until it has that feature. Too easy to steal a master password. Phone security now is basically lower than the security provided by Windows NT’s first release. It’s time to raise the bar.

Nick P • January 29, 2011 6:15 PM

@ Clive Robinson

Shh! Quit telling them about EMSEC and covert channels! How else am I going to untraceably sneak all their trade secrets out of their network from the comfort of my own home? 😉

Kidding aside, I do appreciate you posting the TCP paper. That was some really great work at MIT. Closing that channel without hurting performance would essentially require overwriting their storage area on every TCP packet that enters or exits a given node. A tad complicated in most organizations, don’t you think?

I liked all the good references in the paper more than anything else. I’m curious if it’s even possible to design even a fixed purpose device/app that provably has no covert channels. I recall that the A1 class systems had low bandwidth covert channels they couldn’t get rid of. If they couldn’t do it, what COTS product can?

Dirk Praet • January 29, 2011 7:25 PM

From http://developer.android.com/guide/topics/security/security.html : “Additional finer-grained security features are provided through a permission mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad-hoc access to specific pieces of data.” I think this PoC shows that they are actually still not quite there.

Then again, this can hardly be a surprise to anyone. Smartphone software stacks have yet to reach maturity. As phones have evolved into mini-PC’s and become more and more ubiquitous, so will viruses and malware targeted against them. Can’t wait to see the first smartphone botnet emerging. For now, I’m sticking to my old Motorola until such a time that I feel reasonably assured that the apps running on my future Android-based phone will do so at approximately the same security level as similar apps running on my preferred computing platform(s) today.

Seiran • January 30, 2011 12:41 AM

First, the designers got it right with the blinking satellite icon and watermark when the GPS is in use. First, add a microphone icon to the notification bar (a transparent watermark when the bar is hidden) whenever the microphone is being accessed by a non-system app. Do the same for camera as well.

The permission model needs to be fixed so that users can deny individual permissions to applications. A problem with the Android security model is that it provides no way for users to control usage of permissions, only to grant them or deny installation. It would be nice to be able to be able to have accept, deny and prompt. Or an access level slider.

To further deter applications from insisting on having more permissions than they need, and coercing the user to allow it in order to access the app, much of the functionality could be blinded in a way that prevents the application from being able to determine if the permissions has truly been granted. Some functionality can be “sandboxed” or “virtualized” to provide all existing functionality while increasing security and privacy.

—– in detail,

Blinding:
For example, the Read Phone State and Identity permission includes the ability to read the phone serial (IMEI,ESN,MEID) and the subscriber information. Coupled with network access, this can be used to enforce application licensing, but also poses privacy risks. OLPC’s security model (Bitfrost) might address this by simply preventing the permissions from being combined – as it does by preventing file viewers from accessing the network. I propose a replacement mechanism that preserves privacy, preserves functionality and can optionally preserve identity enforcement. Applications will receive a hashed serial based on the actual serial number and the publisher’s manifest signing key identity (using Pub. To allow access to the actual hardware serial number, for asset inventory apps for example, users must explicity grant that permission. This ensures that applications will receive the same pseudo-serial after an OS reinstall, but prevents serial numbers from being correlated with users across more than one software vendor. If the OS does not permit the user to specify their own custom serial number, software activation mechanisms that are intended to prevent license transfer or to limit the number of trials per device will still maintain their security. However, ad networks will not be able to build dossiers on mobile users.

Virtualizing:
Applications that request Internet, Contact list or SD card access when the user doesn’t want to give that, can be told that the Internet is unreachable, the contact list is empty, and the SD card is empty. The “contact list” and “SD card” can be virtualized, similar to the Android secure partition for application installs. What the app sees as the SD card root is really stored in a folder. Therefore, it can store its map tiles, audio files, saved games and license files – but attempts to trash the SD card won’t affect other application storage. If a user wants a file manager, such as Astro file manager, the app can instruct them that they must go to system setttings, select the app, try to grant additional permissions, go through a “This app can delete your SD card” warning screen with a 5-second delay, and click the OK button after it is enabled.

Prompting:
Another simpler example is the “Service that cost you money, directly place phone calls” feature. An application that shouldn’t need this permission might ask for it, and users will often approve without noticing. To reduce the risk associated with this behavior, Directly Place Phone Calls and Directly Send Messages can be enabled in a Prompt state by default. The very first time the application tries to dial a call, the user will receive a consent dialog with the application name, requested action, a method to check the parameters (phone number, SMS contents) and the ability to auto-accept future requests through the “Don’t ask again” checkbox.

Clive Robinson • January 30, 2011 9:41 AM

@ Nick P,

“I’m curious if it’s even possible to design even a fixed purpose device/app that provably has no covert channels.”

I don’t think so when it comes to anything using the equivalent of a Universal Turing Engine.

Let me put it this way if you go back to the work of Alonzo Church and Alan Turing one thing that came up was the “halting problem”.

In essence it was shown beyond reasonable doubt that it was not possible to decide by analysis if any piece of code would halt or not.

The same reasoning can be applied to any piece of code with respect to subliminal channels. That is just by analysis it is not possible to know if there is a subliminal channel or not. You have to use other methods ie testing in one form or another (which is where the real ComSec secrets lurk 😉

The important point to remember about subliminal channels above all else is that you cannot see them, or touch them, or even usually recognise them if they are previously unknown to you (hence the basis for the ComSec secrets).

The real world solution to the halting problem is the same as that developed at Los Alomos for other reasons and gave rise to “Monte Carlo Methods”.

Essentialy what you do is impose a meaningfull policy or mechanism where by you force the system to halt.

Very aproximatly (sorry maths bods) in Monte Carlo Methods you make a known number of guessed inputs (the policy) and examine the output. Each guess in theory gets you another step closer to the answer. Thus if after a million meaningfull input guesses it has not halted you can say that with a probability of 2^(10^6) it’s not going to halt. However if it does halt then you know definatly 😉

This method used to be used for deciding if a very large odd number was prime or not.

So to stop subliminal channels you would need an an all important appropriate policy. And the weasle word hear is “appropriate”…

Even then you can only say probablisticaly that you don’t have a subliminal channel, or that by policy the app cannot leak a meaningfull amount of information in channel types you are aware of.

This is because you don’t know an unknown channels bandwidth, because you don’t know the data transportation or clocking method etc etc.

All you can say is that you have by design stoped any channel type you are aware of of being able to send X amount of information in Y time and that due to policy the secret S requires more bandwidth to be sent in Y time….

Sounds good but… yes there is a “gaping whole” in that argument as well due to determanistic -v- true random,

For instance let us assume your design is to use 128bit key AES to send only 8bits per encryption and you change the key on each and every encryption as the policy.

You can clearly see there is not enough data bandwidth to send 128 bits of data required to send the encryption key.

However there is a catch any channel will always leak atleast one bit of information (ie it’s in use or not).

Thus you need to take one step back up the chain from the AES encryption key to how it is being generated and synced at both ends (it needs to be done determanisticaly otherwise meaningfull communication could not be establishesd over the 1 bit of “data is being sent”).

If say the AES key is being generated by CTR mode AES, as an adversary you need to know the CTR AES master key and the value of the CTR counter register. This might be only a handfull of bits due to the syncing method employed. Thus being able to leak just one bit per communication (by say timing jitter) could be enough to leak sufficient information to break the system….

Even when you have only one possible data channel how do you decide if what is being sent is not “super-encoded” in some way say by time or against some other factor like power usage, blinking front pannel light, ultra sonic noise caused by resonance in a coil in the PSU or other part of the circuit etc etc…

You can start to see that there are a significant number of ways by which the data and it’s clock can be leaked. And that the amount of data needed in a determanistic system may be very very small and easily unknown to you which brings you back to the Halting problem.

Put simply if the app cannot communicate data or a synchronisation clock in any way it cannot leak information, otherwise all bets are off…

Which gives three possabilities,

1, Stop all communications.
2, Stop data being sent.
3, Stop a clock being sent.

But an app that does not communicate at all is not a lot of use to anyone. So on the assumption the app has to communicate usefully some way the usuall ComSec aproach is to stop the subliminal data being sent in a meanigful way or more correctly to stop it being received in a meaningfull way by the evesdroping party.

The two usuall ways to do this are to first clock the inputs and clock the outputs to the app so that external timing refrences to the app cannot get in other than in a controlled manner, the second trick is to fuzz the app output timing before it is transmitted into a comms channel.

This generaly acts a s a low pass filter stopping all high frequency communication (by timing). The next issue is to stop unwanted low frequency transmission usually this is by randomly breaking up the data being sent down the comms channel in various ways.

Hopefully at this point any clocking synchronisation by timing as well as data sent by time based codes has been effectivly removed.

To remove any illicit data from the app being sent on the comms channel the usuall method is to encrypt again using a different system.

However although this limits the problem it does not solve it.

Another method to aliviate the problem is to run the app so it does not have control over data entering or leaving the app in any way.

One soloution to this is you just feed data into the app and it gets on with it. At some random point you halt the app and examine it’s state, if it is stuck in one state then that is probably the answer (it’s like a moorly state machine in that respect). However that means that if the app can “become aware” of when it has being examined it could in theory change it’s answer for the next examination and in this way leak out information.

All other methods sort of follow one or more of these same ideas.

But as noted above they are not foolproof by any means.

Gabriel • January 30, 2011 11:53 AM

@Clive: it seems the best one can do is reduce throughput. No matter what one does to protect the system, an app still has the ability to be in one of two states, executing and not executing (sleep, wait for io) etc. That’s one horrendously slow bit, but it is a bit. And any os will let you view CPU usage of any process, even privileged, as a mean value. A few extra sleeps, and your usage goes down. A few extra loops with some number crunching (mul div etc) and usage goes up. There’s your bit of data, which can be enough throughput for a larger value if you have all day.

Nick P • January 30, 2011 12:13 PM

@ Clive Robinson

Thanks for your reply. I wanted to correct a statement related to the halting problem and static analysis. Modern formal methods and modelling have gotten around that for certain imperative languages. There are also methods to identify covert channels statically, like info flow analysis and shared resource matrices.

My question was more of is there a way to be sure we’ve found all of them? Thats the one i figure we get a bad answer for. Even with this question, i bet ur answers still apply.

Ryan Ingram • January 30, 2011 12:22 PM

@Clive: I’m not sure your appeal to the Halting Problem and other hard/impossible to decide problems applies here. It’s plenty easy to write a program that you can prove halts: “main() { return 1; }” for example.

So the question is, can you design a system that provably has no side channels? My guess is yes, but that doing so for a system with any sort of useful functionality would be difficult. If I was working on the problem I’d try to come up with a set of composable primitives that have desirable properties, prove things about the primitives and their compositions, and build a program entirely out of those.

But it would probably take orders of magnitude longer than just writing the software to functionality spec, which is why nobody does that. Time to market wins again!

Nick P • January 30, 2011 2:24 PM

@Ryan Ingram

Thats currently the best approach. In spite of market forces, there have been a few that went that far. The SKPP compliant kernels, seL4 kernel, CompCert compiler, Cryptol, GEMSOS, and Verisoft project are examples of the high assurance approach. I think Verisoft has the right idea: create a repository of verified modules that others can use, improve, or add to.

Adam • January 31, 2011 6:09 AM

Android’s finegrained security is fine in theory but in practice it leaves much to be desired. Apps are granted permissions during installation and there is no way to modify or override the permissions afterwards.

I might install a calendar app which asks for SMS permissions. It might need these for a niche feature e.g. to send a reminder to meeting participants. But I as a user have no way to veto the action once the app installed. Perhaps it needs the SMS for a niche feature or perhaps it is malware which texts some premium rate number. How do I know? How can I even tell when it calls out?

I think Android phones should assume that no downloaded app is trustworthy (at least initially). Popups should appear allowing the user to allow / deny certain action which have the potential to cause harm. If the user wishes to trust the app they can check a box which makes the phone remember the decision. But by default assume the worst and at least allow the user to control what permissions it gives out regardless of what perms the app says it needs.

RobertT • January 31, 2011 8:08 AM

@Nick P
If you want something to worry about I have found a way to alter ARM microcontrolers, the compute engine for almost all smart phones, without either ARM or the licensee knowing that the “hard macro” has been altered. This can be used to create hardware side-channels in over 40% of mobile platforms, known ONLY to the individual that created them.

You can talk about software TCB till you are blue in the face BUT it does not count for Jack if the hardware is corrupted!

Kevin Granade • January 31, 2011 10:29 AM

Addressing just one issue: why Android permissions are not revokable.

Unfortunately the reason for this is simple and pernicious, Google has prioritized app ease-of-authoring and “reliability” over security.

Building an application that can gracefully handle the random failure of various APIs is HARD, and the failure mode will not obviously be the fault of the application. All the end user will see is that their apps are unstable. More sophisticated users MIGHT notice that this happens when they have revoked permissions.

Google (probably correctly) predicts that a large number of application authors will not write sufficiently robust software, and that when a user does revoke permissions for an application, application instability will result.

I don’t have a solution for this problem, it is a very difficult one, but I can say I’d prefer to see the approach of trying to have the OS report misbehaving applications instead of trying to make everything “work” even if it means sacrificing various other characteristics of the platform. Security foremost, but it impacts many other areas as well.

moo • January 31, 2011 11:14 AM

@RobertT: Good point. I remember reading about some research into hardware backdoors for modern CPUs, showing that it was possible to implement remotely-triggerable vulnerabilities into a CPU with less than two thousand gates (which is miniscule compared to the hundreds of millions of gates used in modern CPUs). I think this was it:
http://www.usenix.org/event/leet08/tech/full_papers/king/king.pdf

Maybe this is one of the reasons why the NSA has their own chip fab.

David Thornley • January 31, 2011 11:48 AM

The problem is not that the permissions are too coarse-grained, or that they’re irrevocable. The problem is in expecting average users to manage permissions properly.

It’s not reasonable to expect an app to run properly without full permissions, and it’s not reasonable to expect a user to realize why it’s not. Therefore, the permissions should be set to what they’re needed on app installation, and should be reset on app removal. Displaying what permissions the app requires on installation is fine: most people will disregard it, but it won’t be onerous, and a few people might find it useful.

Realistically, most users are incapable of finding the nefarious behaviors possible with permissions, and even if they could they couldn’t tell if a given app was performing said nefarious behavior. Since there’s probably legitimate and illegitimate uses for all possible combinations of permissions, the information is inadequate to judge whether or not to install the app.

Therefore, the permissions review works more as a method of blaming the user than preventing malware, joining numerous other techniques (like UAC and telling users to avoid dodgy websites).

Seiran’s suggestion is a good one: provide visual notification that some app is listening to your phone call. Since the user can’t see the screen while talking normally, it would be best to have it linger for a bit after the call. It should then be possible to find what apps are using what facilities. Most importantly, the user must be able to mark apps as trusted to use those facilities: if the user is used to having app A be active on the call, the user won’t notice from a notification that app B is also.

Clive Robinson • January 31, 2011 1:40 PM

@ Gabriel,

“And any os will let you view CPU usage of any process, even privileged, as a mean value.”

Yes it will (currently), and from the perspective of being on the machine the App is on, the game is effectivly over from this respect.

However it would not be overly difficult to remove the feature and add another process that makes random wildly different demands on the processor and memory such that it would render the information via that route very low bandwidth.

That being said, in my reply to Nick P the view I was looking at was the much more restricted and technically chalanging “black box” view. That is you are looking from the outside of the system be it just the app or the system it is running on. This is a much more technically challenging task for the design of a covert channel, as in theory “you can see” all the available comms channels as you test.

If you can show for this restricted case that you cannot prevent a subliminal channel then it holds for pretty much all cases not just the easy case of “sharing the box”.

Now you have to be careful what you mean by a black box system. In a very limited case it can be a logic lader state machine, through to a full blown computer system.

With a limited state machine where all the states are known, and the data being worked on does not in any way effect the functioning of the black box (such as a simple parity checker through a DSP chip doing a low pass function) it is effectivly working as a filter function.

Such a “filter” function should provide a well charecterised signiture that can be tested with all valid data inputs and any differences in the signiture noted and investigated during testing.

A similar rational applies to some of the “leaf sub” functions of more complex applications where the data can effect the flow of a program down through various levels of subs.

In essence these functions have either a very limited state or no state at all and do not react to the data passing through. That is for these limited functions data values cannot in any way be program values to be potentialy executed. Thus they cannot in any way be considered as a Turing Engine universal or otherwise.

However as you start to add state even though there is no conditional branching the level of complexity rapidly rises as the state effectivly adds to the number of input bits.

[remember for a simple logic circuit each output bit is defined by one of 2^m maps of the input bit permutations of which their are 2^n thus 2^2^n maps are possible. So four input bits gives 2^4 =16 input permutations of which there are 2^16 = 65536 distinct maps one of which defines the response for an individual output bit.]

It thus rapidly becomes impossible to test all potential states for even quite a small function and other methods need to be deployed (usually divide and conquer).

A similar issue of rapidly increasing complexity occurs when conditional branching on data can occur (such as Branch if Not Equal) that is at the simplest you potential have different maps for each branch condition based on the current data and current state relationship.

At this point the data can effect the behaviour of the function and thus it can cause a change in the functions signature that is potentialy visable outside of the function. One such way this can be seen is with a test and decriment loop which effectivly adds a delay proportional to the difference between the current data value and one stored in the functions state..

However even when such loops are eliminated data values will be leaked by other issues such as unbalanced branch behaviour.

Thus writing code to prevent this sort of time related subliminal channel generaly means not using any optomised code by the likes of the compiler and then “hand tuning” which is at best a laborious task.

In general the solution in the past was where possible, to strictly limit the functionality of a sub-function and use a logic ladder or well defined state machine for each sub-function and apply significant controls (re-clocking etc) on the interfaces.

As you can appreciate there is considerable work involved and the whole “bespoke” process is usually very inefficient in it’s utilization of resources.

One area that often gets over looked is “what to do on error”. Just about any error or exception will cause a significant change in the functions signature and this potentialy opens up a whole manner of subliminal channels via timing or resource usage. One simple way of dealing with such issues is “fail hard” and “back off for long random periods”.

In more recent times the use of formal methods has been looked at (have a look at Microsoft’s Verified Code Compiler and Z3). Part of this is so that the designs can be considerably less “bespoke” and also utilise resources more efficiently.

However formal methods whilst potentialy giving a proof of rightness about the code depend extreamly heavily on the correct specification to verify against and the ability of the programer to correctly translate the specification into the appropriate verification code.

Also formal proofs are still quite limited in scope, they cannot be used effectivly against even moderate size code basses with moderate state (such as would be found in a compleate OS).

Thus the “divide and conquer” technique is often used, however as it runs not on seperate hardware instances with carefully controled interfaces a new class of subliminal channels open at the next layer up and all the way up the rest of the stack due to amongst many reasons the issue you identifed of “resource utilization” being visable to all sub-functions either dirrectly from asking the OS or indirectly through testing a resource utilization etc.

However even when formal methods are capable of proving a whole OS you still have to ask if the “specification being tested to” is correct or even possible to prove within a finite time.

Kevin Granade • January 31, 2011 2:21 PM

@David Thomley: You raise good points, but if a provider (which could be the OS author, phone manufacturer, or network provider) isn’t going to manage application permissions directly, then all that can be done is provide the user with tools they can use to manage application permissions themselves.

The proposal of notifying the user when certain resources are used is just another means of helping them manage security for themselves, with all the same problems related to the user being unprepared to do so. As with permission controls, it suffers from the problem of granularity and information overload. How many little blinking icons are you going to put on the screen to notify the user that an app is doing something that is potentially dangerous?

Coming from the other direction, if you’re just worried about call monitoring the problem is simple, but the fact is that there are a smorgasbord of capabilities that a bad application can use to do bad things, and then you have to strike a balance between too-low granularity (rendering the feature effectively worthless since almost everything needs some potentially dangerous capabilities) and too-high granularity (rendering the feature essentially worthless from information overload).

I’m not saying anything new here, but fundamentally I don’t think this is a technology problem, but rather a social problem. We’re still trying to figure out how to strike a balance between enabling features for the user without exposing data about them to bad actors.

Nick P • January 31, 2011 3:19 PM

@ RobertT

Actually, I totally agree and my previous posts on this blog mention the first layer is securing the hardware. I just don’t know how feasible this is at the moment from a platform OEM’s perspective when working with a mobile phone provider. They seem to make their own hardware decisions for reasons other than security. “Oh, it has TrustZone! That sounds so secure!”

Previously, the only semi-secure processor design I’ve seen that minimizes the hardware TCB was the MIT Aegis processor. However, I found a promising new architecture that works ground up to put a root of trust in the main chip that apps can leverage. Look up Princeton’s SecureCore and SP architectures if you haven’t already. They are awesome! Must still put measures in place to prevent backdoors, but these make good building blocks and require minimum alteration to an existing SOC. Vachharajani’s RIFLE framework was also interesting.

@ Clive Robinson

You might want to look at the Princeton SecureCore project as well because they’ve got a nice paper on using Intel’s hyperthreading for covert channels. I KNEW that crap was risky and it’s why I always had it turned off in secure designs. Anyway, they identified a SMT cache channel and a SMT functional unit channel. On a 2.8GHz P4, the cache channel leaked 3.2Mbps!! The functional unit channel was 500Kbps. I always appreciate how Intel applies Moore’s Law to the covert channels we try to remove. Thanks a lot, pricks!

Nick P • January 31, 2011 3:25 PM

@ Kevin Granade

“then you have to strike a balance between too-low granularity (rendering the feature effectively worthless since almost everything needs some potentially dangerous capabilities) and too-high granularity (rendering the feature essentially worthless from information overload).”

Not necessarily. The operating system could employ very fine-grained permissions, but also provide coarse-grained groups of permissions that assign many granular permissions at once. The user could choose how granular of permissions they want to work with. Kind of like how many apps have both Regular and Power User modes.

One feature would be looking at the group permission to see which granular permissions an app needs, then getting rid of the group permission and assigning only the necessary ones. Admins already do this kind of thing when they create specific user accounts for specific applications to limit their privileges. If it’s a business phone, the admin could set the privileges of a given business app and push that out to the phone via a policy like some existing access control frameworks use.

Additionally, with mobile phone virtualization becoming more popular, the admin might keep one copy of each type of Android VM properly configured, update it, and push it out onto the phones in regular intervals. The phone would just have to change the VM rather than all the individual settings, like in desktop virtualization. Is any company doing this currently or did I just invent a new market and tip off the competition in one post? (sighs)

RobertT • January 31, 2011 10:28 PM

@Nick P
I’d suggest you study some of the commercial secure processors, Infineon is a good spot to start. Look at the extreme levels they go to to prevent chip probing (preventing Optical, FiB and Needle probes). Now think about how completely silly this added active protective mesh layer is, if the attacker can have their own registers directly attached to the microcontroller bus, within the chip.

All the attacker has to do is to create some unknown registers that are activated by some unlikely code sequence. with this he can easily create a I/O mapped FIFO that stores small sequences of ALU operations. If you have a multi processor environment it is easy to see how this hardware feature can be used to grab encryption keys and leak them through some unsuspected low bandwidth “side channel”

The big problem is that modern microcontrollers are constructed with feature sizes of 40nm and 60M transistors. New development is happening at 22nm. For those who have forgotten high school physics, violet light is about 440nm, so these features are about 1/20th of a wavelength. This makes it almost impossible to directly view the surface of the chip with any optical microscope.

Put another way, it is practically impossible for the fab’s customer (phone chip design company) to tell if the delivered chip, exactly corresponds to the ordered “taped-out’ chip. Point is the Fab also does not know that the design has been altered and the Chip design company cannot see that changes have been made to the design. They both exist in blissful ignorance that the hardware integrity has been compromised.

Now for the real problem.
At the moment there are about 7 chip design companies seriously involved in the mobile phone space. But only 3 fabs.
In order of importance these are:
Mediatek (Taiwan / PRC design / Fabless UMC)
Qualcomm (US design / fabless TSMC + GSM)
Infineon (now Intel) (fabless TSMC)
STM/NXP/Ericson (Europe) (own fab + TSMC?)
TI (only for Nokia) (own + TSMC)
Spreadtrum (PRC) (unsure SMIC?)
Broadcom (US/UK design / fabless GSM)
Mstar (Taiwan/PRC fabless TSMC + GSM)

Notice that at least 1/2 this design list is Taiwan or China based. And about 80% of the volume is fabbed at one of 3 Asian fabs. (TSMC, UMC and GSM)

In my mind, the combination of these factors, makes the very concept of Trusted phone chip hardware impossible.

RobertT • February 1, 2011 1:28 AM

@moo
Actually I’m suggesting that hardware can be maliciously altered AFTER the design is complete and without the company that designed the chip, even suspecting that ANYTHING was changed.

In essence, I can defeat all their hardware counter-measures and completely bypass all circuit review procedures.

Think about, the absurdity of a online cryptography, if someone can sample ALU register contents at will and communicate these results through a side channel. IMHO the existing production model is that broke.

RobertT • February 1, 2011 2:34 AM

@NickP
If you are interested in the Princeton work, have you read Jeffery Dwoskin’s thesis?
http://www.jeffdwoskin.com/dissertation/DwoskinThesis-20100426-v1.53.pdf

Contains some interesting ideas on the secure hardware concept.

Aissen • February 1, 2011 5:36 AM

Yet another paper without reproducible results.
Where’s the source code ? Are we supposed to take everything at face value ?

eymiha • February 1, 2011 9:51 AM

There needs to be a ‘picture’ of what’s needed by an app (or any code that is being installed) that shows the required routing to information on the system. At least that way, you could see what’s being hit… and the requests could be subject to analysis. Perhaps this could even be used to set up ‘allow’, ‘disallow’ or ‘ask’ properties for the different retrievals, with any unregistered retrieval being blocked. In any case, I like that a lot more than reading fine print.

Nick P • February 1, 2011 2:42 PM

@ RobertT

Thanks for the link. I noticed the name when you posted it: I downloaded all the papers relating to Princeton’s projects about two days ago, but only had time to read a few. Since you mentioned it, I moved it up to the top of my reading list. I definitely think their work, plus maybe Infineon-style chip protection, is the best route right now. That their architecture allows the reuse of existing ISA for running legacy applications just makes it even better. A totally clean slate is nice for security, but markets rarely accept it. I think SecureCore is a nice compromise that doesn’t compromise on security. What you think?

Mark R • February 1, 2011 7:41 PM

The sad thing about this is that we’ve taken a step backwards. I used to own a Nokia phone running Symbian 60. I could grant and revoke individual permissions (network access, local filesystem access, etc.) to applications. I could also make grants temporary and be prompted each time the app requested permission.

Since then, the iPhone exploded and smart phones are no longer for geeks only. Unfortunately this entails a “dumbing down” process; things should “just work” instead of worrying consumers with some fiddly permissions settings. The obvious solution would be an “expert mode” with all the settings exposed, but I’m not sure the manufacturers or telcos have any motivation to fix this.

Clive Robinson • February 2, 2011 9:01 AM

@ Nick P, Robert T,

What many people forget about the “channels” be they subliminal / side / covert, is that they work not only both ways, but also follow the law of unintended consiquences.

For instance there are a number of “security researchers” who should know this but appear for reasons unstated to ignore it.

The area this is most visable in is “Honey Nets” and time based channels. This alows a knowledgable attacker to “enumerate” a network and make a probabalistic determination as to the ratio of “real-:-virtual” hosts on a network segment.

This information can lead to the knowledgable person doing the enumeration of the “unknown” network deciding with good probability if a particular network segment is a honeynet / tarpit etc and thus avoiding them.

Further it enables the person enumerating a network to decide other factors about the network segment based on comparison with other networks.

The logical conciquence of this applies to directed attacks used for intel gathering or as people are talking about “Chinese APT” (see stuff on their j20 stealth plane development).

Put overly simply the enumeration works by looking at things like network time stamps and when they change and by how much.

In the case of TCP time stamps each real physical host has a signiture based on the behaviour of the internal system clock. With a virtual host it is going to show a high corelation with other virtual hosts on the same machine.

Further the change in these signitures is indicitive of the activity on the host (virtual or otherwise) which provide “tells” as to what it is being used for.

All that is required is simple mainly infrequent access to the IP stack from the Internet. This access can be well well below the noise floor for a persistant adversary who is going for stealth.

That is a cautiously tailored attack is effectivly invisable to network based Intrusion Detection/Prevention Systems. If then allied to one of many stealth systems (think some types of mutable memory malware hiding in IO cards etc etc) you have an effective APT tool.

Now something I have been looking into of recent times is to consider the case of “cloud computing”.

With alittle thought you will realise that most of the malware detecting tools available are just not going to work.

For instance IDS etc systems do not have a snow ball in hells” chance of seeing such attacks. Even using non mutable memory for OS images, flushing RAM and hashing BIOS etc is going to come up well short of the mark.

Thus I can confidently predict that the “Chinese curse” of “living in interesting times” is comming true if not as we speak but real real soon now.

RobertT • February 3, 2011 11:52 PM

@Nick P
the problem with preventing hardware hacking is that it’s an arm’s race. Each level of complexity you add reduces the participant’s, but it will never eliminate everyone.

When I look at something like “securecore” I’m asking myself, who just got eliminated? or put another way, who’s still in the game? and what’s the new budget?

If you add complexity but do not substantially change the attack vector cost/participants, than your just wasting money.

WRT “securecore” what does this really mean?

Can it withstand FIB probing attacks?
How about Infrarad backside attacks (Pica)?
Are the DPA obfuscation circuits actually helpful? (see previous comments on LSFR spreading correlation or DSSS rake receivers)
Are RAM contents readable due to data “burn-in”?, numerous attacks use this vector.
Are Jtag (serial chip scan) capabilities really disabled permanently? If so how? can a single fib repair this scan capability?

What happens to registers / RAM in Under-voltage operation? (say 0.3V to 0.4V)

What about super cooling to lock in data?

One aspect that worries me most is the new reliance of magically structures like PUF’s, they are the new secret sauce for the willfully blind. They secretly hold data only that can only be extracted by the authorized program and correct functioning hardware…hmm …my BS meter is hitting the limits!

So all these things look good on paper but they only really do two things
1) delay the time to crack
2) change the skills needed and thereby the cost to crack the hardware.

Nick P • February 4, 2011 11:50 PM

@ RobertT

I appreciate the enumeration of attacks. I agree with your assessment of the two things the defenses do. I like that, though, for most situations. A hardware security technology that requires thousands of dollars, special equipment, special skills, and plenty of time to break would defeat many potential attack vectors and attackers. Well, it would allow us to build systems with a foundation strong enough to do so. I guess intelligence agencies and well-funded spies are still able to crack the things. I think accounting for the devices (and strong penalties for violators) is the best way to defeat the corporate spies.

As for secure hardware, your post indicates that the best strategy is still to physically guard the device or its user using machine-gun toting zealots in a locked down building in the middle of land with no grass/trees and hidden cameras and sensors everywhere (esp. to detect physical tunneling attempts). Good to know how expensive “secure” is. Even then, who knows.

Note: I just realized as I wrote my post that Area 51 uses this approach. I guess that’s some independent validation right off the bat. 🙂

Clive Robinson • February 5, 2011 1:10 AM

@ RobertT,”

Clive Robinson • February 5, 2011 6:40 AM

@ RobertT,

First off my apologies for the above empty post to you. The keyboard driver on this LG Android smart phone decided to “take a walk in the park” again, necesitating a hard reboot. And as my patience with it’s not so little anoyances is wearing thin I went and did something else for a while (one day my patience will end and it will be reboot with a 14lb lump hammer time 😉

So back to your points,

“So all these things look good on paper but they only really do two things
1) delay the time to crack.
2) change the skills needed and thereby the cost to crack the hardware.”

If you think about it the second (2) point is just an example of the first (1) point. That is “cost” is directly equatable with time via resource generation and utilisation.

It is easy to fall into the thought process of,

If I have “one monkey typing for an infinite period of time” the cost is broadly equivalent to having “an infinite number of monkeys typing for one period of time…

However there is the oft forgoton issue of resource “setup time” of getting an infinite number of monkeys and typewriters prior to that one period of time (the falacy of throwing manpower at a problem). And then the “teardown time” of checking the infinite output to find the one true copy of Shakespear’s work and getting into your hand. Which even with another set of infinite resources would take another unit of time to check, then probably an infinite period of time to get it back to your hand (because the square root of unbounded is still unbounded)…

Yes there is an optimal “sweet spot” to be found with bounded problems but again you fall into setup time issues the same as the “traveling salesman” does. So even then you need to hope pobablistic methods (roll the dice) will work in your favour, but… even quite small bounded problems become effectivly unbounded when probablistic methods are employed. That is on occasions throwing the dice will take an infinite period of time to find the result, and on many other occasions it will take longer than the brut force search method…

Thus even in a finite bounded universe with quite a small well bounded problem, time still gets the “last laugh” according to Murphy 😉

So as can be seen the second point (2) is effectivly a special case of the first point (1).

Which gives rise to the question, are their any security measures that are not a subset of (1)?

I would say that with regards to (1) ‘delay the attack’,

“ALL and I do mean ALL security systems do this AND NOTHING MORE…”

thus no.

That is if you think about it sufficiently broadly even “provably secure” crypto such as the OTP will fail to an “end run” around it. That is the attacker simply moves outside of the carefully limited definition of “provably secure” to a suitably low hanging fruit such as a time based side channel.

It is a point that appears lost on many “System Designers”, they see “probably secure” and build it in on the mistaken belief their logic “chain relies on the strongest link”…

Thus missing the point that at the end of the day the security chain for either tangable physical or intangable information assets relies 100% on,

A) 100% control of the asset at all times and,
B) the ability to 100% detect all attacks and,
C) the ability to 100% respond effectivly and,
D) in a sufficiently timely manner 100% of the time.

And it has to be in that order, that is a 100% effective response to an attack after you have lost control of the asset (the horse has left the stable) gets you nothing due to the perfect copy issue.

Thus if the base hardware that directly uses the asset cannot be checked, you don’t have 100% control of the asset so game over, or is it?

Are there ways you can get close to100%?

The answer is yes but there is a catch…

For instance if you know that you have locked the asset up in a safe and the safe is two difficult to break or move you have effectivly dealt with two of the attack vectors against the threat. But not all the catch is there are still other “human” attack vectors etc.

That is each time you identify an attack vector you can mitigate it but the chances are there will be atleast one vector you have either not thought of or not mitigated properly.

Again the question arises “Are there ways you can you get close to 100%?”

And the answer is again “yes with a catch” you can put bounds on the environment such that you reduce classes of attack vectors.

A simple example is the “air gap” provided it is sufficiently large and genuinely nothing crosses it then you have close to a 100% secure system.

There is of course a catch or two, the first of which is how big does the air gap have to be to ensure nothing can cross…

To which the only 100% answer is infinite, but physics appears to come to the rescue with the issue of all active systems suffer from “thermal noise” setting a “noise floor”. That is as a signal gets weaker with the square of the distance, noise floor becomess first comparable and then greater than the signal. So at a finite distance a signal will be comparable to the noise floor…

However there are still catches, the important “noise floor” (that is in the attackers receivers) is not under your control because they can use passive systems such as high gain antennas. Nore is the number of receivers the attacker employes or the spatial way they configure them so the noise floor distance is partly under the attackers control for any given signal.

But further there is another issue that of “signal bandwidth” the noise floor thus the minimum physical distance is also dependant on the bandwidth the attacker choses to use. That is although say the troughput of data to be encrypted is quite high thus having a relativly small noise floor distance. The bandwidth required to leak the encryption key could be very low and thus have a very large noise floor distance and importanly a much different effective carrier frequency to the data…

The other important catch is genuinely isolated systems serve no purpose and will fail. Thus air gaps have to be bridged for the systems to do useful work…

This means the bridges must operate in a restricted environment as well, but to be usefull they need a certain bandwidth which means the bridges are effectivly Shannon Communications channels. The catch is recognising all the channels and controling their “bandwidth, energy/time vectors etc.

Thus the process of securing a system can be likened to that of trying to keep a leaky boat afloat with the only materials available being maluable but porous or non maluable irregular shaped non pourous materials. Thus you can control the leaks you can see but you cann’t stop them, and you can not see all the leaks. So the boat will sink if other measures are not taken.

And it is this “seeing” business that is the issue.

As you note it is not possible to see if the “high end millon+ gate devices” are “backdoored” or not. So the question arises, does this matter?

Actually no, not if you design around it correctly.

Think back to GJ Simmons “prisoners problem”, by deffinition the prisoners (big chips) are untrusted and thus are kept issolated each in their own cell within the prison (environment).

As long as they are kept appart they cannot communicate directly thus if they cannot find a comms channel they have to rely on the good gracess of the prison warden to take messages back and forth between them which he does not have to do.

This lack of communications does not prevent the warden putting the prisoners to work. However if the prisoners work on related processes this does alow for a covert channel to be established.

However an astute prison warder will be aware of this and importantly that there are various steps they can take to “reduce the leaks” but that won’t stop them entirely.

What else can the prison warden do?

Well one thing he can do over and above reducing the basic channel bandwidth (flow) is to stop and start the channel randomly and swap work items in it around both in time and amoungst other prisoners. If the warden does this correctly he can get a fairly good work flow with very reduced covert channel bandwidth.

Further the warden can reduce the size and complexity of the work related items passed between prisoners thus reducing the ability to “hide information” within them.

Further the warden can augment Jeramy Bentham’s “Panoptican” idea and also ensure the prisoners have so much work going through they do not have spare resorces to either establish or use a covert channel.

So the air gap system can be improved by breaking it down into small issolated blocks with multiple units doing small identical parts of the task. The security hypervisor system (warden) randomly routes information through the multiple units (prisoners) along with random padding data (nulls).

Provided the hypervisor takes care in the way it does things no individual block can establish a reliable channel to any other block. Further the size of the data packet sent between the blocks is to small to carry meaningfull amounts of data. And provided there is sufficient capacity the data packets can be tempoarally stored, transposed and mixed with other unrelated or random data.

The system is not 100% but it makes an attackers life extraordinarily expensive in resources and time.

The thing to remember is that although the “prisoners” are unknown quantaties to the “warden”, the “warden” can make the “prison” environment and routien well know to themself but not to the “prisoners”.

So one design choice is to make the packet passing switches and store, in devices you can trust. So just for arguments sake the small dtat packets (assets) gets sent on a serial line to a piece of custom hardware built with very small function large gate size (7400/4000) chips that breaks any timing or power side channels down beyond a usefull “leak” value.

Also you can “share a task” around the prisoners. Think about basic functions like 16/32/64 bit XOR, ADD, SUB and even MUL and DIV with the likes of AES and RSA. Each function is unaware of where it sits within the overall structure, just that it gets input processes and outputs. Further any one function can be chained amongst several functions.

If you have two numbers that need to be added together you can split the numbers either by radix or value or both.

That is 27+31 can be split up by radix as A=7+1+0, B=3+2+0 C=radix*(B+Acarry+0) and D=C+A+0. By value you can simply do A=27+(-13), B=31+(26), C=B+(13), D=A+(-26), E=D+C. And both methods can be combined in various ways especialy using mod(x) techniques. At no point is any ADD node aware of what part of the chain it is nor which value is data and which value is the obsficating value supplied by the hypervisor. Likewise with a little thought the order of the operations can also be randomised. Although somewhat inefficient at all levels the same process can be done with larger functional blocks. Providing the randomization process carried out by the hypervisor is not (sufficiently) determanistic than only the hypervisor knows which node has the valid result.

The trick is thus the old “Divide and Conquer” aided by “Transpose and Randomize” with a further dose of “mixed traffic” and additional “null traffic”.

If done correctly what actually happens is the data side channels get encrypted with a random pad which makes any data leaked effectivly usless. And any covert channels from the nodes gets likewise randomly encrypted, but also due to the mixing of data streams spread across various channels, and at best partialy due to the hypervisor droping the null data as and when it feels like it the node cannot establish a covert channel above a certain bandwidth. Further the storage adds further temporal uncertainty to both the side and covert channels in exchange for delay.

Thus you don’t have to “not use” untrusted hardware you just have to make the attack vectors as near usless as you can whilst maintaing some measure of usefull through put.

Thus you are reducing “efficiency” to gain “security”.

RobertT • February 6, 2011 10:11 PM

@Clive
Lot’s of information, I’m not sure that I agree with everything you wrote, because you seem to place a little too much faith in the integrity of the Hypervisor, especially given that we are talking about an attacker intentionally modifying the hardware.

I agree completely that compute efficiency is the enemy of data security, In my mind the correct implementation of an inefficient process, is the hardware cryptographic equivalent of longer Keys. Both create a data space that is unfeasibly large to directly search (brute force). In the case of Hardware this increased data space must come from random padding random instructions, random timing, and random power usage, around all important operations.

@Nick P
One last thing to remember, the value of a viable hack increases exponentially with the uniqueness of your ability to hack the target hardware, (assuming it is worth doing at all). This last fact guarantees that sufficient resources will flow to the hacker to make the task economically viable, almost regardless of the difficulty level. Think of the process created to crack enigma, if you want a suitable example.

Nick P • February 8, 2011 2:52 AM

@ RobertT

Yeah. This is true so long as the hardware is easily hackable by a particular attacker. I mean, we all know that there are savants and ingenious attackers who can do what most can’t. There are also defensive methods that are notoriously hard to beat. I think that and the further development of these methods keeps the pattern you mentioned in check. Well, at least for groups without enormous and unchecked resources. (Not naming names but I don’t think I have to…)

Nick P • February 8, 2011 2:58 AM

@ Clive Robinson (mostly) & RobertT

“Lot’s of information”

Yeah, he does that. Asperger’s Syndrome, Clive? Haha, maybe or maybe not. Eccentric, for sure. The specifics? Unknown. How can he talk so much and I still don’t know if this is his diagnosis?

“I’m not sure that I agree with everything you wrote, because you seem to place a little too much faith in the integrity of the Hypervisor, especially given that we are talking about an attacker intentionally modifying the hardware.”

Lol, Clive, at least Robert has set the score in peer review: Castles 1, Prisons 0. Haha!

(Although, I’m not sure the castle approach can overcome the stated objections. Perhaps we’re both at 0 on this one. Back to square one or never left it. 😉

Clive Robinson • February 8, 2011 8:21 AM

@ Nick P (mostly and Robert T some),

“Yeah, he does that. Asperger’s Syndrome, Clive Haha, maybe or maybe not. Eccentric, for sure. The specifics?”

I’ll put my hand up to eccentric and even ecclectic (I have a lot of unrelated hobbies including cooking and historical materials research for various types of bows, and a real interest in fieldcraft for living in the middle of nowhere starting from the clothes you stand in). But I’ve never been tested for Asperger’s or any other Autistic Specrum Disorder (I’m way older than that 😉

But back to the “trusting the hypervisor”, the question you should ask first is, “Do I need to trust the hypervisor and if so to what extent?” if you cannot answer this with a reasonable proof this then your are running on assumptions…

However there is the apparently philosophical question of “can you trust a liar?” to which the answer is yes (provided they consistantly lie).

That is the crux of the issue is “consistant behaviour” be it good or bad establishes a level of trust in it’s own right.

The next obvious question is, “How do you know the behaviour is consistant?”

Well the answer is you cannot know absolutely (ie 100%)

But oddly that does not realy matter, for a couple of reasons.

Firstly you can by randomly testing it get a high degree of confidence it’s behaviour is consistant (back to my long running idea of “probabalistic/Monte Carlo Security” 😉

Secondly is the question of “trigger data”, that is the assumption that hidden in the “black box” hypervisor is some unknown piece of logic (code/microcode/gates) that can be activated by the input data. That would once triggered by the input data cause the hypervisors behaviour to cease to be consistant. If you assume you have to “accept it as a hypotheses” (which you should) then you need to think on how to mitigate it in some manner. One simple way is to limit the hypervisor output behaviour options another is by probabilistic means (more of which later).

So asside from the probabilistic parts can you have a hypervisor that exhibit’s the required charecteristics of,

1, Consistant behaviour.
2, Inability to interpret input data as code.

The simple answer is yes.

I have in the past talked about state machines which are hard programed (ie not Turing Machines) and do not treat nor cannot treat their input as a program.

However these are “filters” which we see with the likes of DSP’s etc, and do not take action on the data which is something we need the hypervisor to do.

Well as noted above if you limit the hypervisors output options you limit the attack vectors that can be derived from it.

For instance if you limit the hypervisor output to “good/bad” this puts a limit on what the hypervisor can be tricked into doing ie simple DoS.

Even this is still a communications channel so the next obvious question is “Can information leak or be leaked through this channel?”.

Which brings the hypervisor output into the realms of G Simmons “subliminal channels”, and the question of “Can they all be removed?”.

Which unlike the halting problem is still in the assumed state of “probably not”, thus we err on the side of caution and further assume “no”.

But again does this realy matter?

Actuall probably not for various reasons.

As we have discussed in the past “side channels” are a bit of a “black art” tucked away in the apparently arcane arts of TEMPEST or EmSec.

Where the “known” overiding rules to be applied outside a functional block (black box) are to,

1, limit the bandwidth.
2, Limit the energy in.
3, Clock the inputs.
4, Clock the outputs.
5, Fail hard.
6, Fail long (and random).

The first two being the usual EMC stuff, the second two limit timing channels both from within the black box and importantly through the black box, the last two limit errors being used as a comms channel. There are a number of other rules (such as limiting “coupling”, control sequency etc) but generaly don’t apply till the above are nailed down, but in general are analogous to rule 1 for which ever domain you are looking at.

Then there are all the rules about what goes on inside a functional block such as,

1, No unknown states
2, Limit number of states.
3, Fail to a single state.
4, Limit storage.
5, Decouple Input from output.
6, Decouple output from input.
7, Limit branching.
8, Avoid feedback.
9, Avoid feedforward.
10, No uncontroled loops.

Most of which also apply to “seperation and “segregation of function and data” within a system.

However…. If you examine all the rules you might conclude that they do not stop the potential for low bandwidth channels. This is not quite the case, hidden away in the “coupling” and “decouple” rules is the use of probabalistic methods. We are starting to see this with “fuzzing” and “whitening”.

That is by the use of true random data you can prevent a functional block having sufficient meaningful access to the input data to be able to activate a trigger (except by chance, which would in all probability throw an error somewhere).

As a simple example the trigger might be a series of known values in the data stream at known points. If you “whiten” the input data by either ADD or XOR it does not prevent the functional block carrying out valid activities on the data. For instance branching on equal value, if you add the same whitening value to both the data value and the comparison value then the functional block will work as expected but the functional block will have no idea what the actual unwhitened value is. Likewise if the position is important data can be randomly switched betweeen two identical functional blocks.

I could go on but I hope you have the gist of the idea.

Nick P • February 9, 2011 12:49 AM

@ Clive Robinson

Much better post. The lists content applies to building functionally correct systems in general. State limitation, loop elimination and layering are all good approaches to increasing assurance.

1300 Number • April 7, 2011 12:53 AM

There’s still a possibility that this can happen even if it is just a concept. If given in the wrong hands, who knows right? I hope they can make changes for this in order to protect and secure the fears of their consumers or customers.

Trojan Steals Credit Card Numbers

Comments

Leave a comment Cancel reply