What is a Secure Element as well as why do y'all desire one?
Influenza A virus subtype H5N1 Secure Element (SE) is a tamper resistant smart card chip capable of running smart carte du jour applications (called applets or cardlets) alongside a sure enough degree of safety as well as features. Influenza A virus subtype H5N1 smart carte du jour is essentially a minimalistic computing surround on unmarried chip, consummate alongside a CPU, ROM, EEPROM, RAM as well as I/O port. Recent cards also come upward equipped alongside cryptographic co-processors implementing mutual algorithms such equally DES, AES as well as RSA. Smart cards utilization diverse techniques to implement tamper resistance, making it quite difficult to extract information past times disassembling or analyzing the chip. They come upward pre-programmed alongside a multi-application OS that takes wages of the hardware's retention protection features to ensure that each application's information is solely available to itself. Application installation as well as (optionally) access is controlled past times requiring the utilization of cryptographic keys for each operation. The SE tin move hold upward integrated inwards mobile devices inwards diverse cast factors: UICC (commonly known equally a SIM card), embedded inwards the handset or connected to a SD carte du jour slot. If the device supports NFC the SE is unremarkably connected to the NFC chip, making it possible to communicate alongside the SE wirelessly.
Smart cards lead hold been around for a piece as well as are at nowadays used inwards applications ranging from pre-paid telephone calls as well as transit ticketing to credit cards as well as VPN credential storage. Since an SE installed inwards a mobile device has equivalent or superior capabilities to that of a smart card, it tin move theoretically hold upward used for whatsoever application physical smart cards are currently used for. Additionally, since an SE tin move host multiple applications, it has the potential to supercede the bunch of cards people utilization daily alongside a unmarried device. Furthermore, because the SE tin move hold upward controlled past times the device's OS, access to it tin move hold upward restricted past times requiring additional authentication (PIN or passphrase) to enable it.
So a SE is evidently a really useful matter to lead hold as well as alongside a lot of potential, but why would y'all desire to access 1 from your apps? Aside from the obvious payment applications, which y'all couldn't realistically create unless y'all ain a banking concern as well as lead hold a contract alongside Visa as well as friends, in that place is the possibility of storing other cards y'all already lead hold (access cards, loyalty cards, etc.) on your phone, but that likewise is somewhat of a grayness expanse as well as may requiring contracting the relevant issuing entities. The master copy application for tertiary political party apps would hold upward implementing as well as running a critical component of the app, such equally credential storage or license verification within the SE to guarantee that it is impervious to reversing as well as cracking. Other apps that tin move do goodness from beingness implemented inwards the SE are One Time Password (OTP) generators and, of course of study PKI credential (i.e., someone keys) storage. While implementing those apps is possible today alongside touchstone tools as well as technologies, using them inwards exercise on electrical current commercial Android devices is non that straightforward. We'll verbalise over this inwards especial the minute component of the series, but let's outset explore the types of SEs available on mobile devices, as well as the degree of back upward they lead hold inwards Android.
Secure Element cast factors inwards mobile devices
As mentioned inwards the previous section, SEs come upward integrated inwards different flavours: equally an UICC, embedded or equally plug-in cards for an SD carte du jour slot. This post service is evidently close the embedded SE, but let's briefly review the residue equally well.
Pretty much whatsoever mobile device nowadays has an UICC (aka SIM card, although it is technically a SIM solely when used on GSM networks) of some cast or another. UICCs are genuinely smart cards that tin move host applications, as well as equally such are 1 cast of a SE. However, since the UICC is solely connected to the basedband processor, which is carve upward from the application processor that runs the master copy device OS, they cannot hold upward accessed straight from Android. All communication needs to drib dead through the Radio Interface Layer (RIL) which is essentially a proprietary IPC interface to the baseband. Communication to the UICC SE is carried out using special extended AT commands (
An alternative way to utilization the UICC equally a SE is using the Single Wire Protocol (SWP) when the UICC is connected to a NFC controller that supports it. This is the instance inwards the Nexus S, equally good equally the Milky Way Nexus, as well as piece this functionality is supported past times the NFC controller drivers, it is disabled past times default. This is all the same a software limitation, as well as people lead hold managed to patch AOSP source to larn around it as well as successfully communicate alongside UICC. This has the greatest potential to drib dead component of stock Android, however, equally of the electrical current liberate (4.1.1), it is soundless non available.
AT+CCHO, AT+CCHC, AT+CGLA equally defined past times 3GPP TS 27.007), which the electrical current Android telephony manager does non support. The SEEK for Android projection provides patches that do implement the needed commands, allowing for communicating alongside the UICC via their touchstone SmartCard API, which is a reference implementation of the SIMalliance Open Mobile API specification. However, equally most components that verbalise straight to the hardware inwards Android, the RIL consists of an opened upward source component (rild), as well as a proprietary library (libXXX-ril.so). In social club to back upward communication alongside the UICC secure element, back upward for this needs to hold upward added to both to rild as well as to the underlying proprietary library, which is of course of study upward to hardware vendors. The SEEK projection does supply a patch that lets the emulator verbalise straight to a UICC inwards an external PC/SC reader, but that is solely usable for experiments. While in that place is some verbalise of integrating this functionality into stock Android (there is fifty-fifty an empty packages/apps/SmartCardService directory inwards the AOSP tree), in that place is currently no touchstone way to communicate alongside the UICC SE through the RIL (some commercial devices alongside custom firmware are reported to back upward it though).An alternative way to utilization the UICC equally a SE is using the Single Wire Protocol (SWP) when the UICC is connected to a NFC controller that supports it. This is the instance inwards the Nexus S, equally good equally the Milky Way Nexus, as well as piece this functionality is supported past times the NFC controller drivers, it is disabled past times default. This is all the same a software limitation, as well as people lead hold managed to patch AOSP source to larn around it as well as successfully communicate alongside UICC. This has the greatest potential to drib dead component of stock Android, however, equally of the electrical current liberate (4.1.1), it is soundless non available.
Another cast factor for an SE is an Advanced Security SD carte du jour (ASSD), which is basically an SD carte du jour alongside an embedded SE chip. When connected to an Android device alongside as well as SD carte du jour slot, running a SEEK-patched Android version, the SE tin move hold upward accessed via the SmartCard API. However, Android devices alongside an SD carte du jour slot are becoming the exceptions rather than the norm, so it is unlikely that ASSD Android back upward volition move inwards to the mainstream.
And finally, in that place is the embedded SE. As the call implies, an embedded SE is component of the device's mainboard, either equally a dedicated chip or integrated alongside the NFC one, as well as is non removable. The outset Android device to characteristic an embedded SE was the Nexus S, which also introduced NFC back upward to Android. Subsequent Nexus-branded devices, equally good equally other pop handsets lead hold continued this trend. The device we'll utilization inwards our experiments, the Milky Way Nexus, is PN65N chip, which bundles a NFC radio controller as well as an SE (Android Beam. This is solely cool the outset pair of times though, as well as since the API solely gives y'all higher-level access to the underlying P2P communication protocol, its applications are currently limited. CE was non available inwards the initial Gingerbread release, as well as was introduced afterward inwards social club to back upward Google Wallet. This is the NFC mode alongside the greatest potential for real-life applications. It allows your telephone to hold upward programmed to emulate pretty much whatsoever physical contactless card, considerably slimming downward your physical wallet inwards the process.
The embedded SE is connected to the NFC controller through a SignalIn/SignalOut Connection (S2C, standardized equally NFC-WI) as well as has three modes of operation: off, wired as well as virtual mode. In off mode in that place is no communication alongside the SE. In wired mode the SE is visible to the Android OS equally if it were a contactless smartcard connected to the RF reader. In virtual mode the SE is visible to external readers equally if the phone were a contactless smartcard. These modes are naturally mutually exclusive, so nosotros tin move communicate alongside the SE either via the contactless interface (e.g., from an external reader), or through the wired interface (e.g., from an Android app). This post service volition focus on using the wired mode to communicate alongside the SE from an app. Communicating via NFC is no different than reading a physical contactless carte du jour as well as we'll affect it briefly inwards the finally post service of the series.
And finally, in that place is the embedded SE. As the call implies, an embedded SE is component of the device's mainboard, either equally a dedicated chip or integrated alongside the NFC one, as well as is non removable. The outset Android device to characteristic an embedded SE was the Nexus S, which also introduced NFC back upward to Android. Subsequent Nexus-branded devices, equally good equally other pop handsets lead hold continued this trend. The device we'll utilization inwards our experiments, the Milky Way Nexus, is PN65N chip, which bundles a NFC radio controller as well as an SE (Android Beam. This is solely cool the outset pair of times though, as well as since the API solely gives y'all higher-level access to the underlying P2P communication protocol, its applications are currently limited. CE was non available inwards the initial Gingerbread release, as well as was introduced afterward inwards social club to back upward Google Wallet. This is the NFC mode alongside the greatest potential for real-life applications. It allows your telephone to hold upward programmed to emulate pretty much whatsoever physical contactless card, considerably slimming downward your physical wallet inwards the process.
The embedded SE is connected to the NFC controller through a SignalIn/SignalOut Connection (S2C, standardized equally NFC-WI) as well as has three modes of operation: off, wired as well as virtual mode. In off mode in that place is no communication alongside the SE. In wired mode the SE is visible to the Android OS equally if it were a contactless smartcard connected to the RF reader. In virtual mode the SE is visible to external readers equally if the phone were a contactless smartcard. These modes are naturally mutually exclusive, so nosotros tin move communicate alongside the SE either via the contactless interface (e.g., from an external reader), or through the wired interface (e.g., from an Android app). This post service volition focus on using the wired mode to communicate alongside the SE from an app. Communicating via NFC is no different than reading a physical contactless carte du jour as well as we'll affect it briefly inwards the finally post service of the series.
Accessing the embedded Secure Element
This is a lot of (useful?) information, but nosotros soundless haven't answered the master copy inquiry of this entry: how tin move nosotros access the embedded SE? The bad word is that in that place is no populace Android SDK API for this (yet). The proficient word is that accessing it inwards a touchstone as well as (somewhat) officially supported way is possible inwards electrical current Android versions.
Card emulation, as well as consequently, internal APIs for accessing the embedded SE were introduced inwards Android 2.3.4, as well as that is the version Google Wallet launched on. Those APIs were, as well as remain, hidden from SDK applications. Additionally using them required system-level permissions (
In exercise this is implemented past times the
WRITE_SECURE_SETTINGS or NFCEE_ADMIN) inwards 2.3.4 as well as subsequent Gingerbread releases, equally good equally inwards the initial Ice Cream Sandwich liberate (4.0, API Level 14). What this way is that solely Google (for Nexus) devices, as well as mobile vendors (for everything else) could distribute apps that utilization the SE, because they bespeak to either hold upward component of the essence OS, or hold upward signed alongside the platform keys, controlled past times the respective vendor. Since the solely app that made utilization of the SE was Google Wallet, which ran solely on Nexus south (and initially on a unmarried carrier), this was proficient enough. However, it made it impossible to prepare as well as distribute an SE app without having it signed past times the platform vendor. Android 4.0.4 (API Level 15) changed that past times replacing the system-level permission requirement alongside signing certificate (aka, 'signature' inwards Android framework terms) whitelisting at the OS level. While this soundless requires modifying essence OS files, as well as therefore vendor cooperation, in that place is no bespeak to sign SE applications alongside the vendor key, which greatly simplifies distribution. Additionally, since the whiltelist is maintained inwards a file, it tin move easily hold upward updated using an OTA to add together back upward for to a greater extent than SE applications.In exercise this is implemented past times the
NfceeAccessControl course of study as well as enforced past times the organization NfcService. NfceeAccessControl reads the whilelist from /etc/nfcee_access.xml which is an XML file that stores a listing of signing certificates as well as packet names that are allowed to access the SE. Access tin move hold upward granted both to all apps signed past times a especial certificate's someone cardinal (if no packet is specified), or to a unmarried packet (app) only. Here's how the file looks like:<?xml version="1.0" encoding="utf-8"?> <resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2"> <signer android:signature="30820...90"> <package android:name="org.foo.nfc.app"> </package></signer> </resources>
This would allow SE access to the 'org.foo.nfc.app' package, if it is signed past times the specified signer. So the outset pace to getting our app to access the SE is adding its signing certificate as well as packet call to the
This volition impress the hex string on a unmarried line, so y'all mightiness desire to redirect it to a file for easier copying. Add a novel
As nosotros said, in that place are no special permissions required to access the SE inwards ICS (4.0.3 as well as above) as well as Jelly Bean (4.1), so nosotros solely bespeak to add together the touchstone
With the boilerplate out of the way it is finally fourth dimension to genuinely access the SE API. Android doesn't currently implement a touchstone smart carte du jour communication API such equally JSR 177 or the Open Mobile API, but instead offers a really basic communication interface inwards the
This elementary interface is sufficient to communicate alongside the SE, so at nowadays nosotros simply bespeak to larn access to an instance. This is available via a static method of the
As nosotros mentioned before however,
We tin move of course of study twine this upward inwards a prettier package, as well as nosotros volition inwards the minute component of the series. What is of import to retrieve is to telephone phone
We'll explicate what the response way as well as present how to ship some genuinely meaningful commands inwards the minute component of the article.
nfcee_access.xml file. This file resides on the organization partitioning (/etc is symlinked to /system/etc), so nosotros bespeak root access inwards social club to remount it read-write as well as modify the file. The stock file already has the Google Wallet certificate inwards it, so it is a proficient thought to start alongside that as well as add together our ain package, otherwise Google Wallet SE access would hold upward disabled. The 'signature' attribute is a hex encoding of the signing certificate inwards DER format, which is a compassion since that results inwards an excessively long string (a hash of the certificate would lead hold sufficed) . We tin move either add together a <debug/> chemical element to the file, install it, attempt to access the SE as well as larn the string nosotros bespeak to add together from the access denied exception, or simplify the procedure a combat past times preparing the string inwards advance. We tin move larn the certificate bytes inwards hex format alongside a command similar this:$ keytool -exportcert -v -keystore my.keystore -alias my_signing_key \ -storepass password|xxd -p -|tr -d '\n'
This volition impress the hex string on a unmarried line, so y'all mightiness desire to redirect it to a file for easier copying. Add a novel
<signer> chemical element to the stock file, add together your app's packet call as well as the certificate hex string, as well as supercede the original file inwards /etc/ (backups are ever a proficient idea). You volition also bespeak to reboot the device for the changes to lead hold effect, since file is solely read when the NfcService starts. As nosotros said, in that place are no special permissions required to access the SE inwards ICS (4.0.3 as well as above) as well as Jelly Bean (4.1), so nosotros solely bespeak to add together the touchstone
NFC permission to our app's manifest. However, the library that implements SE access is marked equally optional, as well as to larn it loaded for our app, nosotros bespeak to score it equally required inwards the manifest alongside the <uses-library> tag. The AndroidManifest.xml for the app should await something similar this:<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="org.foo.nfc.app" android:versionCode="1" android:versionName="1.0" > <uses-sdk android:minSdkVersion="15" android:targetSdkVersion="16" /> <uses-permission android:name="android.permission.NFC" /> <application android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" > <activity android:name=".MainActivity" android:label="@string/title_activity_main" > <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <uses-library android:name="com.android.nfc_extras" android:required="true" /> </application> </manifest>
With the boilerplate out of the way it is finally fourth dimension to genuinely access the SE API. Android doesn't currently implement a touchstone smart carte du jour communication API such equally JSR 177 or the Open Mobile API, but instead offers a really basic communication interface inwards the
NfcExecutionEnvironment (NFC-EE) class. It has solely 3 populace methods:public course of study NfcExecutionEnvironment { populace void open() throws IOException {...} populace void close() throws IOException {...} populace byte[] transceive(byte[] in) throws IOException {...} } This elementary interface is sufficient to communicate alongside the SE, so at nowadays nosotros simply bespeak to larn access to an instance. This is available via a static method of the
NfcAdapterExtras course of study which controls both carte du jour emulation road (currently solely to the SE, since UICC back upward is non available) as well as NFC-EE management. So the total code to ship a command to the SE becomes:NfcAdapterExtras adapterExtras = NfcAdapterExtras.get(NfcAdapter.getDefaultAdapter(context)); NfcExecutionEnvironment nfceEe = adapterExtras.getEmbeddedExecutionEnvironment(); nfcEe.open(); byte[] response = nfcEe.transceive(command); nfcEe.close();
As nosotros mentioned before however,
com.android.nfc_extras is an optional packet as well as therefore non component of the SDK. We can't import it directly, so nosotros lead hold to either create our app equally component of the total Android source (by placing it inwards /packages/apps/), or resort to reflection. Since the SE interface is quite small, nosotros opt for ease of edifice as well as testing, as well as volition utilization reflection. The code to get, opened upward as well as utilization an NFC-EE instance at nowadays degenerates to something similar this:Class nfcExtrasClazz = Class.forName("com.android.nfc_extras.NfcAdapterExtras"); Method getMethod = nfcExtrasClazz .getMethod("get", Class.forName("android.nfc.NfcAdapter")); NfcAdapter adapter = NfcAdapter.getDefaultAdapter(context); Object nfcExtras = getMethod .invoke(nfcExtrasClazz, adapter); Method getEEMethod = nfcExtras.getClass().getMethod("getEmbeddedExecutionEnvironment", (Class[]) null); Object ee = getEEMethod.invoke(nfcExtras , (Object[]) null); Class eeClazz = se.getClass(); Method openMethod = eeClazz.getMethod("open", (Class[]) null); Method transceiveMethod = ee.getClass().getMethod("transceive", novel Class[] { byte[].class }); Method closeMethod = eeClazz.getMethod("close", (Class[]) null); openMethod.invoke(se, (Object[]) null); Object response = transceiveMethod.invoke(se, command); closeMethod.invoke(se, (Object[]) null); We tin move of course of study twine this upward inwards a prettier package, as well as nosotros volition inwards the minute component of the series. What is of import to retrieve is to telephone phone
close() when done, because wired access to the SE blocks contactless access piece the NFC-EE is open. We should at nowadays lead hold a working connection to the embedded SE as well as sending some bytes should create a (error) response. Here's a outset try:D/SEConnection(27318): --> 00000000 D/SEConnection(27318): <-- 6E00
We'll explicate what the response way as well as present how to ship some genuinely meaningful commands inwards the minute component of the article.
Summary
Influenza A virus subtype H5N1 secure chemical element is a tamper resistant execution surround on a chip that tin move execute applications as well as shop information inwards a secure manner. An SE is flora on the UICC of every Android phone, but the platform currently doesn't allow access to it. Recent devices come upward alongside NFC support, which is ofttimes combined alongside an embedded secure chemical element chip, unremarkably inwards the same package. The embedded secure chemical element tin move hold upward accessed both externally via a NFC reader/writer (virtual mode) or internally via theNfcExecutionEnvironment API (wired mode). Access to the API is currently controlled past times a organization degree whitelist of signing certificates as well as packet names. Once an application is whitelisted, it tin move communicate alongside the SE without whatsoever other special permissions or restrictions.
0 Komentar untuk "Droidcedas : Accessing The Embedded Secure Chemical Cistron Inwards Android 4.X"