Resources | Resources |



Code Authorization on Brew MP Through Digital Signing

Today, any platform that allows end-users to install applications must defend against malware - code designed to in some way attack the device, the network, or the end-user. Such code may contain a virus or a worm, or may attempt to 'own' the device, log key strokes, access confidential data, degrade mobile network performance, generate unintended billing events, and so on.

There are several complimentary approaches to defending against and mitigating the threat posed by both malware and poorly implemented code. Broadly speaking, there are two approaches. The first strategy is to control what code may execute on the device in an attempt to preclude malware; the second is to limit the services or data a given executable may access to constrain the potential damage it may inflict.

Controlling what code may run

There are several methods to control what runs on a device. A familiar model practiced on most PCs is virus scanning or blacklisting code that should not be allowed on the device. This approach attempts to catch and prevent code from running once it has been identified as malware. Virus scanning is by definition a reactive practice, reliant on continuous and ultimately unbounded updates to detection mechanisms.

The converse approach is to white-list the code that is permitted to execute on the device. This is most effectively accomplished through digitally signing code that you trust. If a platform is configured to permit only the execution of digitally signed code, the user can only install code that has been somehow vetted to ensure that it is not malware. This paper describes in detail how Brew MP supports and relies upon the white-listing of code through digital signing.

Constraining code that runs

To mitigate the havoc that malware, or even poorly acting code, may wreak, it is best to limit the capability of the code to only what is strictly necessary for the code to fulfill its purpose. There are several ways to control what code may do when it is running. These include memory protection across processes through virtualization, or sandboxing, which isolates potential malware from critical system components. (Memory protection is beyond the scope of this paper.) Constraining code is further achieved by restricting the services and data the code may access by controlling the privileges that the code is granted. For example, not every application requires access to user data such as the address book or platform services such as the network.

Control over privileges is much more effective in thwarting bad acting code when privileges are managed and granted by a party vested in the security of the device. Developers are not incented to constrain the privileges granted to their applications and attackers seek the greatest capability they can for their malware. This paper described how code authorization through digital signing on Brew MP provides a mechanism to control the privileges that any given code is allowed.


Brew MP is engineered with proactive defenses against viruses and malware, the cornerstone of which is explicitly authorizing, or white-listing, the code that may execute on the device. This inserts into the software release process an opportunity and a mechanism for device manufacturers or mobile network operators to understand, vet, and even verify the code, its origin, and its developer. Code authorization through white-listing means knowing where the code came from before you run it. Effective white-listing avoids the introduction of anonymous code, which is more likely to be malware.