My Wishlist For A High Assurance, Adaptive Smartphone
Since this is cyber security awareness month, I thought I would do an article about something near and dear to our hearts – the security of our smartphones. A recent article regarding Pentagon plans to approve a smartphone for use at the top secret level got me thinking… maybe the Boeing Black? or a derivative of the General Dynamics/Samsung Knox phone? Or maybe a super stealth Apple 6S Phone? Well, what would be on my wishlist for a TS phone? I mean I have “high assurance” needs like making sure my mobile wallet and associated transactions are secure, my communications are secure and private, my data is protected, my phone is not vulnerable to RATs that spy on me via my phone, and so forth. And, knock on wood, if I ever lose my phone it has a kill switch to self-destruct on command even if I turned the phone off. Maybe these needs are not national security level but it is all relative – right? I also wonder what types of adaptive security defenses might be employed in such a smartphone. So here is a wishlist for my ultra-secure and adaptive [personal] smartphone.
Start with a Tamper-Resistant Platform and MFA
Let’s start with the handset itself. According to Verizon’s latest Data Breach Investigations Report, 15.3% of all data breach incidents are now reportedly due to physical theft or loss. So my “TS” phone needs to be ruggedized, waterproof, tamper-resistant (i.e., any unauthorized attempts to open the casing of the phone will delete the keys that encrypt all my sensitive data), and support remote wipe. Authentication to login to the phone or to open the casing would be multi-factor (MFA) – my preferences are voice and finger biometrics, and a virtual smart card like offered by Microsoft. Microsoft’s virtual smart cards emulate the functionality of traditional smart cards but use the TPM processor on devices rather than requiring the use of a separate physical smart card and reader. I find these mobile MFA approaches easy to use, generally low cost, low in power consumption, fairly quick and with low false positive and negative rates. I would leverage a secure encrypted vault to ensure the privacy and security of the authentication templates using hardware-embedded FIPS 140-2 encryption capabilities – something like Apple’s Secure Enclave or Trustzone’s Trusted Execution Environment (TEE). According to Apple, its Secure Enclave uses encrypted memory and includes a hardware random number generator. Communication between the Secure Enclave and the application processor is isolated to an interrupt-driven mailbox and shared memory data buffers.
Add Some Memory Protection
I also want something like Windows’ Data Execution Prevention (DEP) technology to mitigate memory-based attacks. This defensive technology dramatically narrows the attack surface area for memory related exploits by preventing code from being executable in sections of memory that have specifically allocated for read only data. DEP support is a critically important defense when used in conjunction with Address Space Layout Randomization (ASLR). These core improvements make it more difficult for malware to perform buffer overflow, heap spraying, and other low-level attacks. DEP uses the eXecute Never (XN) bit on the ARM processors in Windows Phone devices to mark blocks of memory as data that should never be executed as code. Therefore, even if an attacker succeeds in loading the malware code into memory, the malware code will not execute. DEP is automatically active in Windows Phone because all devices have ARM processors that support the XN bit.
I would also want to ensure that the phone was not susceptible to side channel attacks, including various forms of power analysis attacks to ensure the protection of my cryptographic keys.
Use a Hardware Root of Trust to Manage Process and Data Integrity and Confidentiality
Now for the system stack. It seems that each of the current crop of secure phones has the ability to execute a secure boot based on using a hardware root of trust for checking and storing hashes or signatures of firmware and other software loaded starting with the initial BIOS. My TS phone would do no less. NIST provides guidance – see Guidelines on Hardware-Rooted Security in Mobile Devices (Draft) – on how this secure boot process should occur. Overall, I really like the Trustzone-based integrity measurement architecture for trusted boot offered by Samsung Knox, however it depends on an enterprise root of trust – “The KNOX Enterprise root of trust is activated when the device is enrolled in an enterprise that has deployed a KNOX-compliant MDM system. This root of trust enables verification of the Samsung Android image with KNOX features activated.” Given this is my personal phone, I go with the Apple 6S Secure Enclave approach, which also seems to be based on a similar ARM Trustzone / GlobalPlatform approach.
Make Sure Apps Are Isolated and Vetted
I also like the concept of Trustzone partitioning resources into “trusted” and “user” worlds. I would add SE for Android Linux policies to the base OS like the Samsung Knox to help control communications better and, reduce threats of tampering, data leakage, and bypassing of application security mechanisms. Today too many apps are engineered to collect and disseminate enormous amounts of user data—such as location, Web browsing histories, device-unique IDs, search terms, and contact lists – data they often simply don’t need. Some app providers also try to obfuscate their data collection functions to get around restrictions by marketplaces such as Apple’s that are intended to prevent abuse of APIs and ensure better privacy for users. For example, researchers have recently discovered hundreds of apps in the App Store that extract personally identifiable user information via private APIs that Apple has forbidden them from calling. The abuser that was singled out – a Chinese mobile advertising developer called Youmi – used simple obfuscation techniques and dynamic linking to get around the application vetting checks performed by Apple. Both the Trustzone partitioning and SE Android serve to minimize the amount of damage that can be caused by malicious or flawed applications such as this, as applications are provided the minimum amount of permission required for their task. This is especially important since, according to Gartner, attackers are changing their tactics to go after the app marketplace rather than explicit attacks on devices, resulting in the majority of breaches through 2017 being caused by “mis-configurations.” Testing tools and environments offered by Veracode, SourceDNA, Perfecto Mobile, Xamarin and others help to ferret out problems in apps before they hit the marketplace. NIST also provides guidance on mobile application vetting here.
Generally, all of the major secure phones including Windows provide some type of secure isolation and hardware-based trust mechanisms in their architecture. In addition to low level system partitioning, roots of trust, and information flow policies, I would look to add additional isolation and fine-grained permission controls further up the stack at the application level using containers. I really want a model that provides total control of applications and data within their own container to enable a powerful solution for the “data leakage” problem. Windows provide a good example of this. For Windows phones, every app and even large portions of the operating system itself run inside their own isolated sandbox called an AppContainer. Apps are isolated from one another and can only communicate using predefined communications channels and data types – similar to SE for Android policies that Samsung uses. This controlled communication capability is especially important since smartphones constantly interact with the outside world – in addition to the traditional network channel, there are many new channels for untrusted data to enter mobile devices. For example, 2D barcodes, RFID tags, media files, the ID field of Bluetooth devices and Wi-Fi access points, beacons, etc. Malicious code can be embedded in data coming from these channels, such as a Javascript code injection attacks.
Mix in Some Adaptive Protections
I would extend this container isolation model with some additional adaptive defensive technologies. First, I would add an API manager that can also emulate API responses to calling apps. In this way I could “grant” permission to simulated files to enable the app to run but not allow access to any actual data. Second, I also like the concept of information rights security over documents, emails, photos, and other data that I may share. A tool such as Vera [albeit an enterprise tool] which gives enhanced control over data and integrates with Google Drive, Box, Dropbox and Microsoft systems including Office 365, Outlook and OneDrive is such an example. Data loss prevention policies are embedded at the file level and travel with the data. Unauthorized users can request to access the data, but can only be granted that access by me – the file’s administrator. Watchdox, recently snatched up by Blackberry, is another DRM/DLP solution for mobile phones. Third, speaking of data protection, I would want multiple layers of encryption – full disk encryption and file or container level encryption. I would also leverage VOIP with encryption as my preferred secure telephony method. Fourth, given that the app market seems to be a major attack vector, I would subscribe to app reputation services such as Lookout to be alerted when a malicious app was discovered and reported. Finally, there are several privacy-enhancing applications provided by the Guardian Project that I would add to my arsenal of adaptive protections.
Discover Blackphone2
When I look back over this wish list for my ultra-secure phone, I realize that the Blackphone2 by Silent Circle satisfies many of these requirements and more. It comes with a full suite of privacy-enabled apps, including Silent Phone, Silent Text, and Silent Contacts. It also offers anonymous search, private browsing, secure cloud file storage, remote-wipe, device recovery tool, secure video chats, and smart disabling of all Wi-Fi except trusted hotspots. It runs a special version of the Android operating system—Silent OS—that blocks many of the ways phones leak data about your activities. Silent OS is an Android fork; it uses Google’s code for the underlying platform, but skips Google Services in the same way Amazon’s FireOS does. Calls and texts made from one Silent Phone user to another are fully encrypted, whether they’re on iOS, Android, or Silent OS. Encryption keys are stored only on the users’ devices (not on any central server) and are destroyed at the end of each call, ensuring complete privacy, every time.
So what platform is your choice as the basis for your ultra-secure phone? I know I just scratched the surface on my wishlist – what is on yours? Give us your comments and let us know some adaptive security capabilities you have run across for mobile platforms. Thanks for reading. ActiveCyber
