Today is Freitag, 26th Mai 2017

Galaxy Nexus: Accessing the embedded secure element and insights into Google Wallet.

Recently the XDA-Developer lukegb described how to run the current version of Google Wallet on the Samsung Galaxy Nexus. There are also other approaches to modify Google Wallet. The devices need to be rooted in order to have all the rights in order to access the embedded secure element of the device. Google Wallet is configured (partly hardcoded) to use the embedded secure element.

Developers can access the embedded secure element with the classes in the package com.android.nfc_extras, especially the NfcAdapterExtras.java and NfcExecutionEnvironment.java. To run applications using these features, you require a special certificate to sign your app. If your device is rooted, you can overcome this „problem“ (= security feature). Currently the API as well as the access condition management (PKCS#15) do neighter comply to the suggestions of the GSMA nor the SIMAlliance.

What can you do?

As a developer you won’t have the keys to the embedded secure element. Therefore you cannot load, delete or modify applications in the secure element (so called applets). According to Google, First Data holds these keys securely. But in the code of Google Wallet there as two AIDs of applets given.

At first there is the card Manager A000000003000000 and secondly the AID of the wallet itself: A000000476201000. You can try selecting them and get some data of the wallet applet using 80CA9F7F00 or 80CA004200.

OTA Management included

Google’s Wallet also includes the OTA Management client acting as the proxy application between the embedded secure element as well as the backend system. The wallet contains URLs such as „https://oma.skcctsm.com/mcp/was/dynamic/url“ or
„https://uat.skcctsm.com/mcp/was/dynamic/url“ which indicate that the TSM Service of SK C&C is contacted. Also the email-address gtec.skcc@gmail.com is used for Google’s Cloud to Device Messaging (C2DM).

During startup of the wallet, the server is contacted and the log output looks the following (x-ed out the TID, the IMEI and the Device ID). It seems that this information is sent to the backend server.

E/TelephonyManager(  556): Original: com.google.android.apps.walletnfcrel, new:
com.google.android.apps.walletnfcrel
D/OTA     (  556): PseudoIMEI = xxxxxxxxxxxxxxxxxxxxx
D/OTA     (  556): deviceID = xxxxxxxxxxxxxxxxxxxxx
D/OTA     (  556): MSISDN =
D/OTA     (  556): RADIO TYPE = GSM
D/OTA     (  556): MNO =
D/OTA     (  556): intentAction = com.skcc.gtec.otaproxy.SCREEN_UNLOCK
D/OTA     (  556): onStartCommand act = StoreRegID
D/OTA     (  556): onStartCommand serviceID = null
D/OTA     (  556): onStartCommand tid = xxxxxxxxxxxxxxxxxxxxx
D/OTA     (  556): onStartCommand instance_seq = null
D/OTA     (  556): onStartCommand mode = pull
D/OTA     (  556): onStartCommand appletAID = null
D/OTA     (  556): onStartCommand instanceAID = null
D/OTA     (  556): onStartCommand appletVersion = null
D/OTA     (  556): getIsConnect netFlag = false
D/OTA     (  556): act = StoreRegID

A detail security analysis by viaForensic can be found here.

MNOs, the SIM and SEEK

Currently Google Wallet is only available to customers of Sprint. What’s important here is, that Sprint runs a CDMA network, where no SIM card is required. So the only secure element in the device is the embedded secure element from Google. To say it the other way around: Sprint needs the embedded secure element of Google for NFC payments. Therefore Google did a good deal to enter the market, as the other MNOs — such as Verizone — want the SIM card be the secure element (the only!) in the device.

Yet there is no API in the devices for accessing the SIM cards. Additionally also a secure layer is needed in order to manage the access to the applets on the UICC and/or the embedded secure element. The GSMA and the SIMAlliance already agreed on a method (which was proposed by Gemalto). This method is already implemented in the most current version of SEEK, which can be directly integrated into Android.

NFC enabled Android devices without an embedded secure element can be manufactured with a PN544 (without embedded secure element, only SWP support) instead of the PN65n. This is possible as both chips have the identical PINs. There are already models of the Samsung Galaxy S II without embedded secure element.


Welcome at nfc.cc

Authors

Top