Michael Roland's blog

JRC u'smile concluded

mroland — Fri, 23 Aug 2019 13:07:24 +0000

After 5 years of research in mobile security, the Josef Ressel Center for User-friendly Secure Mobile Environments (u'smile) was successfully concluded on September 29th, 2017.

The mission of this Josef Ressel Center for User-friendly Secure Mobile Environments (u'smile) was the analysis of security issues in current and future mobile applications; the design, development, and evaluation of concepts, methods, protocols, and prototypical implementations for addressing them; and communication and co-ordination with industry partners and standardization organizations towards establishing globally accepted standards for secure, interoperable, mobile services. Broadly summarizing, JRC u'smile succeeded with many specific contributions towards this vision, and in producing a final prototype of the Austrian mobile driving license on Android smartphones, which brings together the lines of research pursued within the 5 years. In the following report, we summarize these research directions by work packages, focusing on innovations since the two-term evaluation report. Detailed research results have been presented in peer-reviewed publications as well as technical reports, which form an appendix to this summary report. Over the last 5 years we published 18 journal articles, 61 papers in conference proceedings, 5 PhD theses, 2 books, and 22 technical reports and specification documents summarizing our findings and introducing new concepts, methods, and protocols to overcome security issues in mobile devices and applications, and to improve usability of security mechanisms on mobile devices both for end-users and developers. Further, a total number of 24 master's and 14 bachelor's theses have been completed within the scope of the JRC u'smile. Moreover, we were able to present the project and its results to a broad audience by organizing the Android Security Symposium in 2015 and 2017. Additional indicators of success are numerous invitations to talks - including keynote speeches at academic conferences and other events as well as TEDxLinz -, media articles, invitations to participate in discussions with policy makers, and an increased international recognition of Austrian research contributions in the area of mobile device security. JRC u'smile was split into two modules:

Module 1 (Hardware, Platform, and Protocol Security Support for Mobile Devices) aimed to analyze and improve the current state-of-the-art of security in mobile devices specifically on the hardware, middleware, API, network protocol, and user interaction levels. Major contributions within all 5 years include significant advances in biometric, token, and multi-device based authentication methods for smart phones, a comprehensive analysis and protocol design towards an open ecosystem for tamper-resistant hardware in mobile devices, high-level results on securing mobile user interactions, and the integrative research on digital identities for real-world interaction, demonstrated in the Austrian mobile Driving License (AmDL) system.
Module 2 (Security Support for Mobile Services, Libraries and Applications) aimed to improve application security on the higher layers of the smartphone stack, complementing module 1 in tackling the whole stack across the JRC. The work in this module resulted in improvements to users security and privacy, enhancements for secure network communications of applications, self-defense of users concerning security and privacy issues in applicatins and the creation of analysis tools to detect implementation flaws as well as malicious applications.

As predicted in the original project proposal, the mobile landscape is changing rapidly and mobile device security has experienced significant developments beyond the JRC u'smile over the last few years. While the initial motivations and visions remained valid and continued to drive the overall focus of the JRC u'smile, new fields - particularly in the areas of user and cross-device authentication as well as network level privacy implications - have opened, public interest in certain areas - such as digital identities - has dramatically increased, and requirements have changed. At the same time, some of the initially proposed research areas - most prominently virtualization on smart phones - had to be abandoned due to the shift of resources into new directions and due to unforeseen inaccessibility of proprietary technologies based on competitive market forces. We are happy to report that most milestones were met and that the critical path of our planned research has been fulfilled despite these rapid and often unpredictable developments in the mobile domain. Nevertheless, several changes to the original project plan proposed in the project application were necessary:

Some work packages in both modules were merged in order to account for tight relationships and to benefit from improved outcomes through a holistic approach.
A new industry partner - Österreichische Staatsdruckerei GmbH - could be acquired in the area of digital identity use-cases. This allowed us to install a new work package focusing on providing digital identity documents and services on/with mobile devices.
The original concept of virtualization on smart phones to compartmentalize single devices into multiple 'security zones' was successfully prototyped and evaluated on the user interaction level to give guidance on future products, but could unfortunately not be implemented in a full-stack prototype due to unavailable low-level access to the boot loader and TrustZone layers.

The addition of the new work package on digital identities also resulted in an additional project outcome: the Austrian Mobile Driving License (AmDL), a prototype of a privacy-preserving mobile driving license. This shared demonstrator successfully integrates and show-cases results spanning across all work packages and across both modules of the JRC u'smile. Moreover, with this demonstrator we achieved the goal of the initial motivating vision of the JRC u'smile: to - globally, securely, and intuitively usably - substitute current wallets and key chains by suitable services and applications on mobile phones. Finally, specific follow-up projects with partners from the JRC u'smile include the proposal for a new Christian Doppler Laboratory 'Digidow' to extend the JRC vision of digital identities far beyond mobile devices and into cloud services, and the extension of the JRC TARGET with a third module to transfer our collected knowledge on application analysis and system security improvements.

Rainhard Findling received the Fred Margulies Award 2015

mroland — Tue, 06 Dec 2016 14:31:27 +0000

After being awarded the OCG Incentive Award FH 2014, our co-worker Rainhard Findling has also been awarded the Fred Margulies Award 2015 (the award ceremony was on October 14th, 2016) for his master's thesis "Pan Shot Face Unlock: Towards Unlocking Personal Mobile Devices using Stereo Vision and Biometric Face Information from multiple Perspectives". The Fred Margulies award is awarded annually by the International Federation of Automatic Control (IFAC) Advisory Board Austria (German: IFAC Beirat Österreich) for outstanding Austrian scientific work in the field of automation, with special emphasis on social aspects. Laureates are selected by an international jury based on innovation, scientific content, economic and social relevance, and interdisciplinarity.

Photo: Copyright FH OÖ

The thesis investigates the pan shot face unlock: a mobile device face unlock, where users slide their device - with the device camera pointing towards them - 180 degrees from one side of their head over the face to the other side ("pan shot"). The approach combines 2D and 3D visual face data (grayscale and range camera images, if available) from different perspectives of the 180 degree swipe with sensoric information (device rotation from devices' built-in gyroscope sensors). The combination of these measurements is used to determine if the face swipe was done by the legitimate user or an illegitimate user, trying to get unauthorized access to the device.

In terms of cognitive load, the approach is conceptually more user-friendly than currently widespread unlock approaches, such as PIN, password or unlock patterns. It does not require users to remember a secret to unlock their devices (which would get more complicated with an increasing amount of devices owned per user). In comparison to traditional face unlock approaches, the pan shot face unlock is harder to circumvent using photo or video attacks. Traditional face unlock approaches usually only utilize frontal face information - which can easily be obtained by attackers today (e.g. pictures from social media platforms). These can be used to circumvent the unlock using a photo attack (attacker presenting the images or videos to the device to unlock it). With the pan shot face unlock, an attacker would be required to obtain 2D and 3D face data of the legitimate user from multiple perspectives, and to present that data to the locked device while rotating it accordingly - which significantly raises the effort for a successful attack.

"The question of today's high-tech society no longer is, if we want to use some new technology, but how long we can afford not to use it. Therefore, it is of paramount importance to design technology in a sustainable, secure and safe way - including the increasing amount of mobile devices we all own," says Rainhard Findling. Rainhard further wants to thank his supervisor René Mayrhofer for the in-depth support throughout the studies, employment and thesis, as well as his colleagues and his family for their steady support.

Open Mobile API implementations affected by code injection vulnerability [CVE-2015-6606]

mroland — Mon, 25 Jan 2016 11:01:57 +0000

We recently found a severe weakness in implementations of the Open Mobile API deployed on several Android devices. The vulnerability allows arbitrary code coming from a specially crafted Android application package (APK) to be injected into and executed by the smartcard system service component (the middleware component of the Open Mobile API implementation). This can be exploited to gain elevated capabilities, such as privileges protected by signature- and system-level permissions assigned to this service. The affected source code seems to originate from the SEEK-for-Android open-source project and was adopted by various vendor-specific implementations of the Open Mobile API, including the one that is used on the Nexus 6 (as of Android version 5.1). Several Android devices as well as the open source implementation SEEK-for-Android (only versions before 4.0.0) are affected.

We initially reported this issue to affected parties starting end of June 2015 and it was initially announced in the October 2015 Nexus Security Bulletin. The Common Vulnerability and Exposures ID (CVE) identifier CVE-2015-6606 has been assigend to this issue.

Today, we published our report Executing Arbitrary Code in the Context of the Smartcard System Service (arXiv:1601.05833 [cs.CR]) describing this vulnerability in full detail. Further, we published example exploit code to reproduce the issue on GitHub. Patches that fix the issue by disabling add-on terminal loading are available from our website: for SEEK 3.1.0 and for SEEK 3.0.0. Where possible, we strongly advise to upgrade to SEEK version 4.0.0 which contains a completely redesigned add-on terminal loading concept and is consequently no longer affected by this vulnerability.

OeSD joins u'smile consortium

mroland — Mon, 29 Jun 2015 13:39:58 +0000

Österreichische Staatsdruckerei recently joined the u'smile project consortium.

https://www.staatsdruckerei.at/news/oesterreichische-staatsdruckerei-set...

http://futurezone.at/science/staatsdruckerei-will-smartphone-sicherheit-...

Rainhard Findling received the OCG Incentive Award FH 2014

mroland — Wed, 10 Jun 2015 09:55:35 +0000

On 9. June 2015 our co-worker Rainhard Findling has been awarded the OCG Incentive Award FH 2014 (German: OCG Förderpreis-FH) by the Austrian Computer Society (OCG) for his master's thesis "Pan Shot Face Unlock: Towards Unlocking Personal Mobile Devices using Stereo Vision and Biometric Face Information from multiple Perspectives". The OCG Incentive Award FH is awarded annually to Austria's best master's theses at Universities of Applied Sciences in the field of computer science and information management. This is the second time in a row that this award goes to a student at the University of Applied Sciences in Hagenberg. Rainhard studied at the Department of Mobile Computing, University of Applied Sciences Upper Austria. He wrote his thesis during his time as a junior researcher at the Josef Ressel Center for User-Friendly Secure Mobile Environments (u'smile).

Photo: Copyright OCG / Daniela Klemencic

Book Security Issues in Mobile NFC Devices published by Springer

mroland — Thu, 26 Mar 2015 15:20:47 +0000

The revised version of my PhD thesis Security Issues in Mobile NFC Devices was published by Springer in the series T-Labs Series in Telecommunication Services this month. It is available as an e-book and in hardcover.

The book provides an assessment of the current state of Near Field Communication (NFC) security, it reports on new attack scenarios, and offers concepts and solutions to overcome unresolved issues. The work describes application-specific security aspects of NFC based on exemplary use-case scenarios and uses these to focus on the interaction with NFC tags and on card emulation. The current security architectures of NFC-enabled cellular phones are evaluated with regard to the identified security aspects.

Get more information on Springer.com,
read it on Springer Link, or
buy it on Amazon.com.

The recent emergence of Near Field Communication (NFC) enabled smart phones lead to an increasing interest in NFC technology and its applications by equipment manufacturers, service providers, developers, and end-users. Nevertheless, frequent media reports about security and privacy issues of electronic passports, contactless credit cards, asset tracking systems, NFC-enabled mobile phones, and proprietary contactless technologies suggest that NFC is a potentially unsafe technology whose main beneficiaries are thieves. While these weaknesses are often bound to specific applications and products, they boost the fear that NFC technology as a whole is dangerous, threatens our privacy and helps identity theft and fraud. In order to defend their own products and services, manufacturers and service providers often position themselves on the opposite extreme, stating that their products and services incorporate sufficient countermeasures.

This work aims for assessing the actual state of NFC security, for discovering new attack scenarios and for providing concepts and solutions to overcome any identified unresolved issues. Based on exemplary use-case scenarios, application-specific security aspects of NFC are extracted. The current security architectures of NFC-enabled mobile phones are evaluated with regard to the identified security aspects. As a result of the exemplary use-cases, this research focuses on the interaction with NFC tags and on card emulation. For each of these two modes of NFC, this thesis reveals attack scenarios that are possible despite existing security concepts. For the interaction with NFC tags, a new attack scenario is introduced that allows modification of tag content even though its authenticity and integrity were supposedly guaranteed by a digital signature scheme. Moreover, potential privacy issues and remaining problems have been identified in the NFC Forum's signature scheme specification. For the card emulation scenario, the mobile phone itself is identified as a significant, yet unconsidered, threat. Specifically, the well-known concept of relay attacks on smartcards is extended to the mobile phone platform. By using the phone's processing capabilities and communication facilities, relay attacks can be mounted in a significantly easier and less obvious way. These assumptions are verified through prototypical implementations. Possible solutions and workarounds to overcome these issues are outlined and evaluated with regard to their advantages and disadvantages.

How to root Android 5.0.1 on your Sony SmartWatch 3 (SWR50)

mroland — Thu, 29 Jan 2015 16:38:23 +0000

In my previous post I started to dissect the NFC functionality of our Sony SmartWatch 3 (SWR50). Unfortunately, without having root access it is pretty much impossible to explore the whole file system of the watch. More specifically, the interesting parts of the file system (device files under /dev and certain application binaries under /system/bin) are concealed from the adb shell user by SELinux. Therefore, we aimed for getting root access on our SWR50.

Luckily, there was already a guide for rooting the SWR50 available on XDA Developers: [GUIDE][ROOT] Smartwatch 3 KNX01V. This guide worked like a charm on our watch that was still running Android 4.4W (KNX01V). Unfortunately, we then upgraded to Android 5.0.1 (LWX48P) and, eventhough the su binaries survived the upgrade, the su command no longer managed to gain root permissions. As a first shot we tried to re-run the rooting boot image from the guide. This wasn't a good idea though. BE WARNED! Booting the watch with that boot image soft-bricked our device. The device still booted into Android but never started the Android UI due to haning in an endless loop. After I recovered from that shock and after some time (hours?!) of debugging, I — luckily — managed to recover from that soft-brick by (simply) wiping the data partition.

In order to find out what happened, I downloaded the Android Image Kitchen toolchain and extracted the root file system from the rooting boot image. After analyzing the startup scripts of the rooting boot image, the answer to this question was rather simple: This happened because the init scripts of the boot image perform a whole bunch of modifications on the data partition of the watch. While these modifications were just the same that are performed during a regular boot of KNX01V, these modifications were incompatible with the new layout of the data partition in Android 5. Hence, Android 5.0.1 (LWX48P) got stuck in a boot loop.

I, then, decided to create a less intrusive version of the rooting boot image by removing all unneccessary parts of the init scripts. The new image only mounts the system partition, starts a minimal set of system components and (as the original rooting boot image) executes a script (/sbin/superuser.sh in the root file system of the image) containing the commands to install the su binaries. Particularly, the new version no longer touches the data partition. You can download this image here. However, this does not solve the problem of getting root privileges on Android 5.0.1. The method of rooting included into that image is simply incapable of obtaining root privileges on Android 5.

Consequently, I decided to digg a bit deeper into the prerequisites of rooting Android 5. Luckily, Chainfire already did a great job on creating SuperSU for Android and making it available as an update.zip ready to be installed through recovery mode. So all I had to do was to extract the installation script and the installable files from the UPDATE-SuperSU-v2.40.zip file. I used version 2.40, which was the most current version at that time. I then ported the installation script to the /sbin/superuser.sh shell script of the rooting boot image. Moreover, I reduced the SuperSU installation to only the core components necessary to gain root access through adb shell. Specifically, I included the su binaries for the SWR50 hardware platform only and skipped the installation of the SuperSU UI app. You can download this new image here (and this repository contains the source files for image creation using Android Image Kitchen). A quick test (boot that rooting boot image and wait until the watch reboots into Android) revealed that SuperSU 2.40 is capable of obtaining root privileges on LWX48P.

So I already got root and, when you read so far, certainly want to know how to get root on your SWR50 too. Therefore, I created this step-by-step tutorial (heavily based on XorZone's original guide on XDA Developers):

Have a current version of the adb and fastboot binaries on your computer (e.g. by installing an up-to-date version of the Android SDK Tools) and have them on your path.
Download the rooting boot image SWR50-rootboot-for-LWX48P-byMR.img.

Enable the Developer options for your watch (go to Settings -> About and quickly tap the Build number 7 times in a row).

Enable ADB debugging (under Settings -> Developer options). The watch will request confirmation to allow ADB debugging through the companion app on your phone the first time you use the adb tool from your computer.

You may need to install the Android ADB Composite Interface device driver for your watch.

Use the adb reboot command to boot into fastboot boot loader mode:

adb reboot bootloader

If the bootloader of your watch is not already unlocked, you will need to unlock it. On our watch the bootloader was already unlocked by default, so we could simply skip this step.

BE WARNED: This step will wipe all your data from the watch.

fastboot oem unlock
fastboot oem unlock
fastboot format cache
fastboot format userdata
fastboot reboot

After the device rebooted, you have to boot it into fastboot boot loader mode again:

adb reboot bootloader

Boot the rooting boot image:

adb boot SWR50-rootboot-for-LWX48P-byMR.img

The image will boot into a screen "SmartWatch 3" and will stay there for several seconds. When the rooting boot image completed its tasks it will automatically reboot into the regular Android system.

You can now test if rooting succedded by starting adb shell and executing the su binary:

adb shell
shell@tetra:/ $ su
root@tetra:/ #

You can then check if you really got root privileges (and are not locked out by SELinux) by typing ls -l /data which should result in a directory listing like the following:

root@tetra:/ # ls -l /data
ls -l /data
adb
app
app-asec
app-lib
app-private
bugreports
dalvik-cache
data
dontpanic
drm
gps
local
lost+found
media
mediadrm
misc
property
resource-cache
security
system
tombstones
user
root@tetra:/ #

We are not the only ones playing around with the Sony SmartWatch3 SWR50. Hence, while preparing this post there appeared an alternative approach for rooting the watch. Perpe did a great job in porting the TWRP recovery to the SWR50. Therefore, an alternative approach for rooting is to flash (or just to boot) that recovery image and then install the SuperSU update.zip package.

Is there NFC on Sony SmartWatch 3 (SWR50)?

mroland — Mon, 15 Dec 2014 17:41:21 +0000

We recently received our brand new Sony SmartWatch 3 SWR50 (powered by Android Wear). We intend to use them in our research on ShakeUnlock where we try to transfer authentication state transfer between two devices equipped with accelerometers by briefly shaking both devices together. Until then, I decided to explore that device to find out what else we could possibly do with it. As my research focus is (among other mobile security topics) on Near Field Communication (NFC), I was really happy to see that the specs read "Connectors: NFC". Particularly when it comes to access control scenarios (e.g. door access) or payment, using a smart watch instead of (or in addition to) a regular smartcard or a mobile phone could be very convenient. So I was hoping to see host-based card emulation (HCE) functionality. Moreover, I would love to see my NFC TagInfo app running on a smart watch and being able to scan tags with the watch.

About a month ago, a question (and its answer) on StackOverflow already revealed a white paper by Sony that states that the SWR50 only supports NFC "to power on the SWR50 and [to] start the Android Wear host application". If that was really the case, the watch would not be usable for the above scenarios.

So let's see what we found...

First, I started by scanning the SWR50 with another smart phone using my NFC TagInfo app.

NFC TagInfo identified the SWR50 as an NFC Forum Type 2 Tag. The ATQA (answer-to-request) of the tag is 0x0044 and the SAK (select acknowledge) is 0x00. This indicates that the tag supports a proprietary protocol on top of ISO/IEC 14443-3 (e.g. Type 2 Tag platform) but that it does neither support ISO-DEP (ISO/IEC 14443-4) nor NFC-DEP (NFC peer-to-peer mode).

The 7-byte-UID of the NFC tag of our watch is 2e020d00000000 (and it remains the same after rebooting the device). So the manufacturer ID (0x2e) identifies Broadcom as the chip manufacturer. This information (in combination with the fact that this is a Type 2 Tag) is interesting for two reasons:

I did not find any information that Broadcom manufactures Type 2 Tags.
The UID contains a rather unusual number of zero bytes.

Both make me think that this NFC tag might actually be emulated using a Broadcom NFC controller.

Just to make sure that my NFC TagInfo app did not miss anything, I decided to also scan the watch with NXP's TagInfo app. And, in fact, NXP's app found something very interesting: Even though the SAK byte does not indicate support for ISO-DEP, the watch returns an ATS (answer-to-select) in response to a RATS (request answer-to-select) command. The ATS is 0578808002 and codes

FSCI = 8: Maximum frame size from reader to tag is 256 bytes.
TA(1) = 80: Only 106 kbps supported in both directions.
TB(1) = 80: Frame waiting time is 77.33 ms. Start-up frame guard time is 302 us.
TC(1) = 02: CID (card identifier) supported, NAD (node addressing) not supported.

Hence, this further backs my hypothesis that the Type 2 Tag is actually emulated using an NFC controller that supports more than just being a Type 2 memory tag.

The tag 488 bytes of memory in total (split into 122 blocks with 4 bytes each) filled with the following data:

     0: 2E 02 0D 0C     1: 00 00 00 00
     2: 00 00 FF FF     3: E1 11 3C 0F
     4: 00 00 00 01     5: 03 78 30 35
     6: 03 31 D4 0F     7: 1F 61 6E 64
     8: 72 6F 69 64     9: 2E 63 6F 6D
    10: 3A 70 6B 67    11: 63 6F 6D 2E
    12: 67 6F 6F 67    13: 6C 65 2E 61
    14: 6E 64 72 6F    15: 69 64 2E 77
    16: 65 61 72 61    17: 62 6C 65 2E
    18: 61 70 70 FE    19: FF FF FF FF
    20: 30 A8 DB F2    21: 43 1C FF FF
    22: 30 A8 DB F5    23: 2A 78 FF FF
    24: 14 39 2D 4D    25: F2 6A 91 40
    26: FF FF FF FF    27: FF FF FF FF
   ...: FF FF FF FF   ...: FF FF FF FF
   120: FF FF FF FF   121: FF FF FF FF

The static lock bits (block 2, bytes 2 and 3) are all set (indicates locked state).
Block 3 contains a capability container for a Type 2 tag (magic byte 0xE1).
However, the mapping version number 1.1 (0x11) does not comply to any of the current mapping version documents provided by the NFC Forum! The only mapping version number that is currently defined (as of version 1.2 of the NFC Forum Type 2 Tag Operation specification) is 1.0.
Block 4 contains 3 NULL TLVs (0x00) and the first byte of a Lock Control TLV (tag 0x01).
The Lock Control TLV indicates that there are 48 lock bits located starting at byte position 232 (= 7 * 2⁵ + 8). I.e. 6 bytes starting at block 58, so they are all set (FF FF FF FF FF FF). Each lock bit locks 3 bytes, so they indicate that blocks 16 to 51 are locked.
Block 6 contains the start of an NDEF Message TLV (tag 0x03, length 0x31). The NDEF message consists of a single NDEF record (Android Application Record for app com.google.android.wearable.app):

+--------------------------------------------+
| TNF:  EXTERNAL TYPE                        |
| Type: urn:nfc:ext:android.com:pkg          |
+--------------------------------------------+
| Payload: com.google.android.wearable.app   |
+--------------------------------------------+

Block 18 contains a Terminator TLV (tag 0xFE) indicating the last TLV block within the tag memory area.
Blocks 20 and 21 (first 2 bytes) contain the device Bluetooth address.
Blocks 22 and 23 (first 2 bytes) contain something that looks like a Bluetooth address too.
Blocks 24 and 25 contain the device serial number.
The remaining blocks are all filled with FF FF FF FF.

To summarize this, the NFC tag contains a static NDEF message that is used to launch the companion app on an NFC-enabled Android smart phone and to discover the peer Bluetooth address of the smart watch. Moreover, there are some hints that this NFC tag might be emulated using a full-blown NFC controller.

Next, I wanted to dig into the NFC capabilities that are provided to app developers through the Android API. Unfortunately, requesting an instance of the NFC adapter fails as the getDefaultAdapter() method returns null:

NfcManager nfcMgr = (NfcManager)mContext.getSystemService(Context.NFC_SERVICE);
NfcAdapter nfcAdapter = nfcMgr.getDefaultAdapter();  // -> null

This is a clear indication that there is no Android NFC stack available on the device. In addition there is a log message that the device does not support NFC:

V/NFC: this device does not have NFC support

Moreover, looking at the NFC system features, none of the NFC system features are available:

PackageManager pkgMgr = mContext.getPackageManager();
boolean featureNfc = pkgMgr.hasSystemFeature("android.hardware.nfc");      // -> false
boolean featureHce = pkgMgr.hasSystemFeature("android.hardware.nfc.hce");  // -> false

As both, featureNfc and featureHce, are false, neither NFC (android.hardware.nfc) nor HCE (android.hardware.nfc.hce) are available.

Consequently, there currently is no NFC API available on the SWR50.

Last, I decided to run adb shell to analyze the file system of the smart watch Android firmware. The interesting things that I found are:

There is a file named BCM43341B0_002.001.014.0122.0174.hcd under /system/vendor/firmware, so it seems that the watch contains Broadcom's BCM43341 quad-radio chip which also contains an NFC controller.
/proc/misc lists a bcm2079x device driver. The BCM2079x family is Broadcom's family of NFC controllers. This is also the type of NFC controller that's integrated into the BCM43341. Consequently, it seems that the low-level driver necessary to interact with the NFC controller (that is supposedly integrated into the smart watch) is compiled into the kernel. This does not necessarily mean that the driver can actually be used to communicate with the NFC controller though.
There is no NFC service app (Nfc*.apk) on the /system partition. This confirms what we already found out with our analysis of the NFC API: There is no NFC stack integrated into the Android system and, consequently, there is no NFC functionality accessible from apps.

So, even though there might be support for NFC from the hardware side and the kernel side, the user-space part of the NFC stack is missing. Though, the kernel driver might just as well point to nowhere (i.e. might not represent a device that is actually backed by hardware). And the firmware of the BCM43341 might be coded in a way that the NFC controller simply emulates the Type 2 tag while being inaccessible from the operating system.

After some hands-on experimenting, testing and exploring the file system of the Android OS on the watch, it seems that, unfortunately, the description in the white paper is right. At least for now, the smart watch exposes only an NFC tag with a static NDEF message that is used to launch the companion app for the watch. No NFC functionality is accessible through apps. However, seeing that the watch contains a BCM43341 featuring a full-blown NFC controller as well as the fact that the bcm2079x device driver is compiled into the kernel give us a bit of hope that the watch may support more NFC functionality in the future (either through an official firmware upgrade or through some custom ROM).

UICC access with SEEK in CyanogenMod on Galaxy S2/S3

mroland — Tue, 10 Sep 2013 13:47:06 +0000

In our last blog post SEEK adaptations in RIL for Galaxy S3, we analyzed the RIL commands for APDU-based access to the UICC on Samsung's Galaxy S3 and provided some first details on how we implemented this functionality in our SuperNexus-based SuperSmile Android ROM. Now we want to go a step further and provide step-by-step instructions on how to integrate this functionality into CyanogenMod for Samsung's Galaxy S2 and Galaxy S3 (and possibly other devices based on Exynos 4).

First of all, you need to grab the CyanogenMod source:

$ mkdir cm-10.1
$ cd cm-10.1
$ repo init -u git://github.com/CyanogenMod/android.git -b cm-10.1

Note: We also provide a patch for CM 10.2, so you may use -b cm-10.2 as well.

$ repo sync
$ cd vendor/cm
$ ./get-prebuilts
$ cd ../..
$ source build/envsetup.sh
$ breakfast i9300

Note: Instead of (or in addition to) i9300 (Galaxy S3) you can also get the device specific code for Galaxy S2 (i9100) using breakfast i9100.

When you got your working copy of the CyanogenMod repository ready, you can apply SEEK's SmartCard API patches (download them here, you find them in smartcard-api-3_0_0.tgz):

$ curl -O https://seek-for-android.googlecode.com/files/smartcard-api-3_0_0.tgz
$ tar zxf smartcard-api-3_0_0.tgz
$ patch -p1 < smartcard-api-3_0_0/smartcard-api.patch
$ patch -p1 < smartcard-api-3_0_0/uicc.patch
$ patch -p1 < smartcard-api-3_0_0/emulator.patch

Now we have the CyanogenMod source tree with SEEK. While SEEK already provides patches for APDU-based access to the UICC through the RIL (uicc.patch and emulator.patch), these patches only work for the Android emulator and not for real devices. Therefore, we need to modify the RIL interface to permit APDU exchange with the UICC on real devices. Both, the Galaxy S2 and the Galaxy S3 are based on the Exynos 4 SoC platform. Their RIL interface is encapsulated in SamsungExynos4RIL.java (in frameworks/opt/telephony/src/java/com/android/internal/telephony/). So all we need to do is implement the Exynos 4-specific versions of the commands for UICC access in SamsungExynos4RIL.java:

iccOpenChannel(...) for opening a communication channel to an applet on the UICC,
iccExchangeAPDU(...) for sending APDU commands to the UICC, and
iccCloseChannel(...) for closing a previously opened communication channel.

First, we define some constants to tag the responses to the above commands so we can later detect them in the response message handler:

    private static final int RIL_OEM_HOOK_RAW_EVENT_EXCHANGE_APDU_DONE = 1;
    private static final int RIL_OEM_HOOK_RAW_EVENT_OPEN_CHANNEL_DONE  = 2;
    private static final int RIL_OEM_HOOK_RAW_EVENT_CLOSE_CHANNEL_DONE = 3;

Then, we add the methods to invoke the three commands (see our previous blog post for details on the implementation of these commands, the command message formats and the response message formats):

    @Override
    public void iccOpenChannel(String AID, Message result) {

        if (AID == null) {
            AID = "";
        }
        
        byte[] aidBytes = new byte[AID.length() / 2];
        for (int i = 0; i < aidBytes.length; ++i) {
            aidBytes[i] = (byte) Integer.parseInt(AID.substring(2 * i, 2 + 2 * i), 16);
        }
        
        ByteArrayOutputStream commandByteStream = new ByteArrayOutputStream();
        DataOutputStream commandOutputStream = new DataOutputStream(commandByteStream);
        try {
            commandOutputStream.writeByte(21);
            commandOutputStream.writeByte(9);
            commandOutputStream.writeShort(4 + aidBytes.length);
            commandOutputStream.write(aidBytes);
        } catch (IOException ex) {
            Log.e(LOG_TAG, "CMD_OPEN_CHANNEL: open failed", ex);
        }
        
        if (RILJ_LOGD) riljLog("sendRawRequest/iccOpenChannel: AID=" + AID);
        
        // inform response handler that this is an open channel request
        result.arg1 = RIL_OEM_HOOK_RAW_EVENT_OPEN_CHANNEL_DONE;
        
        invokeOemRilRequestRaw(commandByteStream.toByteArray(), result);
    }

    @Override
    public void iccExchangeAPDU(int cla, int command, int channel,
                                int p1, int p2, int p3, String data,
                                Message result) {

        ByteArrayOutputStream commandByteStream = new ByteArrayOutputStream();
        DataOutputStream commandOutputStream = new DataOutputStream(commandByteStream);
        try {
            commandOutputStream.writeByte(21);
            
            int commandLength = 12;
            if (p3 == -1) {
                commandOutputStream.writeByte(12);
            } else {
                commandOutputStream.writeByte(11);
                ++commandLength;
            }
            
            byte[] dataBytes = null;
            if (data != null) {
                dataBytes = new byte[data.length() / 2];
                commandLength += dataBytes.length;
                for (int i = 0; i < dataBytes.length; ++i) {
                    dataBytes[i] = (byte) Integer.parseInt(data.substring(2 * i, 2 + 2 * i), 16);
                }
            }
            
            commandOutputStream.writeShort(commandLength);
            commandOutputStream.writeByte(cla);
            commandOutputStream.writeByte(command);
            commandOutputStream.writeByte(p1);
            commandOutputStream.writeByte(p2);
            if (p3 != -1) {
                commandOutputStream.writeByte(p3);
            }
            commandOutputStream.writeInt(channel);
            if (dataBytes != null) {
                commandOutputStream.write(dataBytes);
            }
        } catch (IOException ex) {
            Log.e(LOG_TAG, "CMD_ECHANGE_APDU: send failed", ex);
        }
        
        if (RILJ_LOGD) riljLog("sendRawRequest/iccExchangeAPDU: " +
                               "channel=0x" + Integer.toHexString(channel) +
                               ", cla=0x" + Integer.toHexString(cla) +
                               ", command=0x" + Integer.toHexString(command) +
                               ", p1=0x" + Integer.toHexString(p1) +
                               ", p2=0x" + Integer.toHexString(p2) +
                               ", p3=0x" + Integer.toHexString(p3) +
                               ", data=" + data);

        // inform response handler that this is an exchange APDU request
        result.arg1 = RIL_OEM_HOOK_RAW_EVENT_EXCHANGE_APDU_DONE;
        
        invokeOemRilRequestRaw(commandByteStream.toByteArray(), result);
    }

    @Override
    public void iccCloseChannel(int channel, Message result) {

        ByteArrayOutputStream commandByteStream = new ByteArrayOutputStream();
        DataOutputStream commandOutputStream = new DataOutputStream(commandByteStream);
        try {
            commandOutputStream.writeByte(21);
            commandOutputStream.writeByte(10);
            if (channel != 0) {
                commandOutputStream.writeShort(8);
                commandOutputStream.writeInt(channel);
            } else {
                commandOutputStream.writeShort(4);
            }
        } catch (IOException ex) {
            Log.e(LOG_TAG, "CMD_CLOSE_CHANNEL: close failed", ex);
        }
        
        if (RILJ_LOGD) riljLog("sendRawRequest/iccCloseChannel: channel=0x" + Integer.toHexString(channel));
        
        //inform response handler that this is a close channel request
        result.arg1 = RIL_OEM_HOOK_RAW_EVENT_CLOSE_CHANNEL_DONE;
        
        invokeOemRilRequestRaw(commandByteStream.toByteArray(), result);
    }

Now we can send smartcard commands to the UICC. Next, we need to detect and decode the responses to the above commands. All three commands are wrapped inside an OEM_HOOK_RAW RIL request. We, therefore, need to intercept the response to this request and decode the responses to our new commands into the format expected by SEEK.

First, we want to intercept the response to OEM_HOOK_RAW. We, therefore, change the default handler for RIL_REQUEST_OEM_HOOK_RAW from responseRaw(...) to our customized handler responseRawCheckRequest(...):

    @Override
    protected void processSolicited (Parcel p) {
        [...]
        if (error == 0 || p.dataAvail() > 0) {
            // either command succeeds or command fails but with data payload
            try {switch (rr.mRequest) {
            [...]
            case RIL_REQUEST_RESET_RADIO: ret =  responseVoid(p); break;
            case RIL_REQUEST_OEM_HOOK_RAW: ret =  responseRawCheckRequest(p, rr.mResult); break;
            case RIL_REQUEST_OEM_HOOK_STRINGS: ret =  responseStrings(p); break;
            [...]

Within our new method responseRawCheckRequest(...), we need to check if the corresponding OEM_HOOK_RAW request was tagged with one of our RIL_OEM_HOOK_RAW_EVENT_* constants. If we find a tag, we need to decode the response into the format expected by SEEK, otherwise we pass the response to the original responseRaw(...) method:

    protected Object responseRawCheckRequest(Parcel p, Message mResult) {
        if (mResult == null || p == null) return responseRaw(p);
        
        Object ret = null;
        byte[] responseByteArray;
        int channel = 0;

        switch(mResult.arg1) {

For the iccExchangeAPDU(...) command, the response APDU (byte array) needs to be converted into an IccIoResult object (by splitting the R-APDU into the data field and the two bytes of the status word):

            case RIL_OEM_HOOK_RAW_EVENT_EXCHANGE_APDU_DONE:
                if (RILJ_LOGD) riljLog("iccExchangeAPDU done");
                
                responseByteArray = p.createByteArray();
                if (responseByteArray != null) {
                    if (RILJ_LOGD) riljLog("iccExchangeAPDU: received response byte array: " + IccUtils.bytesToHexString(responseByteArray));
                    if (responseByteArray.length >= 2) {
                        ret = new IccIoResult(
                            responseByteArray[responseByteArray.length - 2] & 0x0ff,
                            responseByteArray[responseByteArray.length - 1] & 0x0ff,
                            Arrays.copyOf(responseByteArray, responseByteArray.length - 2));
                    }
                }
                break;

For the iccOpenChannel(...) command, the response contains the assigned channel ID and the R-APDU that was received in response to the applet selection command. SEEK currently only processes the channel ID and does not expect a select response. Therefore, we extract the channel number and drop the select response. Note, however, that the SEEK SmartCard API contains a method to get the select response. Therefore, we should forward this select response to SEEK in a future implementation. For now the getSelectResponse() method will return null even if a response had been received.

            case RIL_OEM_HOOK_RAW_EVENT_OPEN_CHANNEL_DONE:
                if (RILJ_LOGD) riljLog("iccOpenChannel done");
                
                responseByteArray = p.createByteArray();
                if (responseByteArray != null) {
                    if (RILJ_LOGD) riljLog("iccOpenChannel: received response byte array: " + IccUtils.bytesToHexString(responseByteArray));
                    if (responseByteArray.length > 0) {
                        int channelLength = responseByteArray[0] & 0x0ff;
                        if (responseByteArray.length > channelLength) {
                            for (int i = channelLength; i > 0; --i) {
                                channel <<= 8;
                                channel |= responseByteArray[i] & 0x0ff;
                            }
                        }
                    }
                }
                ret = new int[]{ channel };
                break;

For the iccCloseChannel(...) command, SEEK does not process the response, so we simply forward any received response byte arrays:

            case RIL_OEM_HOOK_RAW_EVENT_CLOSE_CHANNEL_DONE:
                if (RILJ_LOGD) riljLog("iccCloseChannel done");
                
                responseByteArray = p.createByteArray();
                if (responseByteArray != null) {
                    if (RILJ_LOGD) riljLog("iccCloseChannel: received response byte array: " + IccUtils.bytesToHexString(responseByteArray));
                }
                
                ret = responseByteArray;
                break;

If this response to OEM_HOOK_RAW is not the result of any of our three new commands, we pass the response to the original responseRaw(...) method:

            default:
                ret = responseRaw(p);
                break;
        }
        
        return ret;
    }

Finally, we have to account for differently numbered error codes between the SEEK implementation and the actual behavior of Samsung's Exynos 4 RIL. We define the error code constants for Exynos 4:

    private static final int RIL_OEM_ERROR_MISSING_RESOURCE  = 29;
    private static final int RIL_OEM_ERROR_NO_SUCH_ELEMENT   = 30;
    private static final int RIL_OEM_ERROR_INVALID_PARAMETER = 27;

Then, we check any received error codes for these values and translate them to the values expected by SEEK:

    @Override
    protected void processSolicited (Parcel p) {
        [...]
        if (error != 0) {
            switch (rr.mRequest) {
                [...]
            }

            switch (error) {
                case RIL_OEM_ERROR_MISSING_RESOURCE:  error = MISSING_RESOURCE;  break;
                case RIL_OEM_ERROR_NO_SUCH_ELEMENT:   error = NO_SUCH_ELEMENT;   break;
                case RIL_OEM_ERROR_INVALID_PARAMETER: error = INVALID_PARAMETER; break;
                default: break;
            }

            rr.onError(error, ret);
            rr.release();
            return;
        }

Now you can compile your CyanogenMod ROM with APDU-based UICC access through SEEK (comparable to the stock ROM on Galaxy S3 and some versions of the Galaxy S2) for your Galaxy S2 or your Galaxy S3.

You can grab the patches here:

for CyanogenMod 10.1 and
for CyanogenMod 10.2.

Thanks to Nikolay for debugging, testing with his S2 and the lively discussion.

Michael Roland's blog

JRC u'smile concluded

Rainhard Findling received the Fred Margulies Award 2015

Links

Open Mobile API implementations affected by code injection vulnerability [CVE-2015-6606]

OeSD joins u'smile consortium

Rainhard Findling received the OCG Incentive Award FH 2014

Links

Book Security Issues in Mobile NFC Devices published by Springer

Abstract

How to root Android 5.0.1 on your Sony SmartWatch 3 (SWR50)

So why did this happen?

Creating a less intrusive rooting boot image

Getting root on the SWR50 with Android 5.0.1 (LWX48P)

I want root too! — A step-by-step tutorial

Prerequisites

Step 1

Step 2

Step 3

Step 4

Step 5 (conditional)

Step 6

Step 7

There is an alternative approach too!

Is there NFC on Sony SmartWatch 3 (SWR50)?

NFC Tag

Tag Memory

NFC API

Firmware / Android System

Summary

UICC access with SEEK in CyanogenMod on Galaxy S2/S3