Michael J May

Karthik Bhargavan

Towards Unified Authorization for Android

Android applications that manage sensitive data such as email and files downloaded from cloud storage services need to protect their data from malware installed on the phone. While prior security analyses have focused on protecting system data such as GPS locations from malware, not much attention has been given to the protection of application data. We show that many popular commercial applications incorrectly use Android authorization mechanisms leading to attacks that steal sensitive data. We argue that formal verification of application behaviors can reveal such errors and we present a formal model in ProVerif that accounts for a variety of Android authorization mechanisms and system services. We write models for four popular applications and analyze them with ProVerif to point out attacks. As a countermeasure, we propose Authzoid, a sample standalone application that lets applications define authorization policies and enforces them on their behalf.

Work performed while visiting INRIA.

.

Introduction

The Android operating system seeks to foster a rich ecosystem of third-party applications. Users may download apps from reputable stores managed by Google and Amazon or directly from app developers. 3 This leaves users vulnerable to malware masquerading as genuine apps. Consequently, Android provides strong runtime isolation, running each application process in a separate Dalvik virtual machine, and giving each a private storage area. Isolated applications may still share files and data, for example using external storage or using an inter-app messaging mechanism called intents. While some apps freely share and collaborate with others, those holding sensitive data are tempered by the need for security and integrity. Android therefore provides authorization mechanisms which let an app control which other apps, if any, can read or write its data.

System Permissions Android protects its system resources through permissions which are granted by the user at installation time and accompany the app throughout its lifetime. The Android SDK defines about 130 built-in permissions of which some forty are signature/system permissions and are reserved for the operating system or apps installed by the device manufacturer [START_REF] Varma | Security permissions in android[END_REF]. The rest can be requested by an app in its application manifest, an XML file which is prepared by the developer and stored in its application package (APK) file. When an app attempts to access a system API function at run time, Android first checks if the requestor has the required permission. If it doesn't, a security exception is thrown. Some examples of regular permissions are: READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions to read or write to the phone's shared disk (referred to informally as the SD card since its default mount point is /mnt/sdcard/ [START_REF]Android 4.1 Compatibility Definition[END_REF]), INTERNET to open network sockets, and READ_LOGS4 to access the system log. Some examples of system permissions are: INSTALL_ PACKAGES to install new applications, BRICK to disable the phone completely, and DELETE_CACHE_FILES to clear the cache directories of other apps.

Application-level Authorization In addition to install-time permissions, Android provides a variety of other authorization mechanisms. Activities can filter which intents will be directed to them based on the intent's content or requested action. Content providers and services can be made available only to applications which have certain permissions. Authorization may seem seamless to the user, but due to the variety of tools available and the details of the OS, it can be technically messy and sometimes can even be bypassed.

Consider, for example, a user who installs Dropbox (www.dropbox.com), uses it to download a PDF file from the cloud, and opens it with Adobe Reader (adobe.com/products/reader.html). 5 The user would assume that during the transaction Adobe Reader got temporary read access to the file and nothing more. As we discuss later, that is not the case at all: Adobe Reader and (up until API level 16) all of the applications on the phone can read the file indefinitely afterwards. Many can modify it too.

Our Contribution There are many ways in which applications get authorization wrong or fail to enforce authorization properly. They fail primarily because they don't define the policy they are trying to enforce and (likely) didn't use a full model of the environment during testing. Proper modeling of the environment and the application's behavior would reveal attacks on the authorization mechanism.

Our contribution in this work is threefold. First, we present a unified picture of the Android authorization tools, something not previously presented in a single work. Second, we show how many popular sharing applications on the market fail to get authorization right and publish a formal model of the Android authorization tools and environment which allows us to reveal attacks. We publish the model so that others can use and extend it to test their apps. Third, we present Authzoid, a sample authorization app which properly implements the authorization tools that the apps got wrong. The code can act as a source code module to be included as is or as a starting point for developers who want to get authorization right. Both code and model are found at: http://prosecco.gforge.inria.fr/Essos/pv/.

The rest of this paper is organized as follows. Section 2 explains the Android authorization tools. Section 3 discusses our attacker model, gives technical descriptions of the sharing applications surveyed, and explains the attacks against them. Section 4 contains our formal model for Android authorization tools, environment, and the applications studied. Section 5 discusses the Authzoid app and its major features. Section 6 contains related work and Section 7 concludes.

Authorization for Android Applications

Android applications are composed of four kinds of run time entities:

Activities correspond to windows and allow for user interaction via a GUI. Content Providers provide SQL-like interfaces to queryable data. Broadcast Receivers listen for broadcast messages from other application components, the operating system, or other applications. Services run in the background and provide long term functionality without providing a user interface.

Applications exchange messages via intents which contain a URI data field and strings, URIs, or key-value pairs in extra fields. They are routed by an Android component called Binder between the run time entities. During routing, the Activity Manager writes the action, sender, recipient, and data field (but not the extra fields) to the log. Each runtime entity may use a variety of authorization mechanisms to control access to its data and functionality. In the rest of this section we review the five authorization mechanisms available and explain their usage, strengths, and weaknesses. For each mechanism, we give an example of how it is used in a popular application currently available from the Android Market. Some apps use a combination of the mechanisms below to enable a variety of user policies.

Android Permissions Android's SDK includes about 130 permissions, but an app may extend them with its own permissions by adding them to its manifest file. Apps can use permissions to enforce authorization in one of two ways.

First, content providers, activities, services, and broadcast receivers can specify that only applications with a certain permission may access them. For activities and services, this prevents applications without the permission from invoking or binding to them. For content providers, separate read and write permissions may be given. For broadcast receivers, it prevents the delivery of broadcasts from apps without the permission. The filtering is done automatically by Binder based on the app's manifest file (android:permission for activities, services, and broadcast receivers and android:readPermission and android:writePermission for content providers) or as defined programmatically if they are configured in code.

Example: K-9 Email (code.google.com/p/k9mail/) uses the custom permissions com.fsck.k9.permission.READ_ATTACHMENT to protect its attachments content provider. Its email messages content provider protects read access with READ_MESSAGES and write access with DELETE_MESSAGES. GMail (gmail.com) and Yahoo! Mail (mail.yahoo.com) (discussed below) use a similar strategy.

Second, apps can use the system API to discover whether it, the app which called it, or another app has a particular permission (using checkPermission() or checkCallingPermission()), regardless of its type. They can then make programmatic decisions based on the results.

Example: Some plug-in libraries (ex. ACRA (code.google.com/p/acra/)) programmatically investigate which permissions are available to their host applications before attempting actions which require particular permissions (ex. reading the log and sending internet data).

URI Permissions

The content provider read and write manifest permissions give blanket read and write access. Alternatively, a content provider can give specific read or write query access to a single content URI under its authority. The URI permission can be granted programmatically using grantUriPermission() or by sending an intent to the recipient with the FLAG_GRANT_READ_URI_PERMISSION or FLAG_GRANT_WRITE_URI_PERMISSION flags set. URI permissions can be delegated by recipients. Intent-granted URI permissions are valid until the recipient app closes or is killed. Programmatically-granted ones are valid until revoked using revokeUriPermission().

Binder enforces URI permissions by tracking the grants, revokes, and intents sent, so the URI does not need to be secret. Also, since intents can be routed by capability, the sender may not know which app received the permission.

Depending on whether the content URI refers to a database row, a file, or both, the recipient can use a content resolver request to read or write the corresponding rows or file. If the URI is opened as a file using openFile(), the content provider returns an open file descriptor for it and Binder assigns ownership of it to the recipient.

Example:

Users can open an attachment from K-9 Email with an external viewer. When this happens, K-9 Email sends an intent to the viewer with a content URI for the attachment and the URI read permission flag set. The recipient can then use a content resolver to resolve the URI to an open file descriptor. GMail and Yahoo! Mail employ a similar strategy.

The use of open file descriptors leads to some technical inconveniences. First, since a file descriptor is a hard link to the file and is owned by the recipient, the sender can't close the file descriptor or delete the file until the recipient closes it. Second, if two application hold open file descriptors for the same file (i.e. they both requested the same URI), they cause read/read and read/write conflicts and race conditions. Third, only a few classes in the Java file API support file descriptors, making it impossible to perform random access reads or writes to the file and making rewinding difficult. Because of these issues, some applications immediately make local copies of files passed to them by URI (ex. Adobe Reader) or don't enable updates to such files (ex. Jota Text Editor (sites.google.com/site/aquamarinepandora/home/jota-text-editor)).

Private Storage Every Android application is given its own user name, group name, and home directory. The home directories are protected by Linux file and directory permissions and by default no app can read or write the home directory of another. Apps can override the default settings to make files or directories world readable, writable, or executable using setReadable(), setWritable(), and setExecutable(). Then any other app can read, write, or execute the files or directories. If an app makes a file world readable in order to share it, it may include a long random string in the path to make it hard for unintended apps to guess the path name. This technique turns the path name into a secret, so the app must ensure that only the intended recipient gets the path name.

Example: Unlike most apps which keep all files in private storage private, Google Drive (drive.google.com) (discussed below) selectively sets path read and execute permissions to enable others to read files in its private storage.

External Storage (SD Card) Most Android devices have a shared storage space for files or data (the SD card). Read and write access to the SD card require the permissions mentioned above. Many applications (ex. the camera, the default browser's downloads folder) use the SD card for storing files that are either too large to keep in private storage or that are meant to be available for other apps to use. Aside from the read and write permissions, Android does not enforce access control on the SD card, so any application can read, write, or delete any file on it. Authorization can be enforced on the SD card using encryption or message authentication codes (MAC).

Example: The password storage app 1Password (agilebits.com/onepassword) stores its encrypted password database on external storage. It doesn't share passwords directly with other apps, instead using the clipboard to copy and paste passwords. Encryption protects the contents of the password database and MACs protect its integrity.

Web Sharing Some apps place data to be shared on a public web site and send the URL for the data to another app via an intent. Often the URL contains a long random string to make it difficult to guess, turning the URL into a secret. Another option is to protect the URL using web-based application or user authentication such as OAuth [START_REF]The OAuth 2.0 Authorization Protocol[END_REF].

Example: MyTracks (www.google.com/mobile/mytracks/) uses GPS information to track where the device has gone, including distance traveled, speed, and elevation change. When sharing a "track" from MyTracks with another app, it first uploads a custom map to Google Maps and then sends a web URL with a long random part to the recipient via an intent.

Summary The authorization tools listed show the variety of mechanisms available. It's not clear if any or all of the tools are sufficient to achieve a satisfactory authorization policy. The applications that we study in the next section use different combinations of the tools to enforce authorization, but each suffer from attacks and weaknesses that demonstrate that using them correctly is not simple. In some, the tools are used incorrectly; in others, features of the Android environment defeat the app's authorization policy.

Applications and Attacks

To investigate how popular applications use the authorization tools of Section 2 to enforce their security goals, we study four apps: two Email clients and two Cloud File Storage applications. We explain each application's authorization mechanism and explain how an attacker may defeat it.

Authorization Goals and Attacker Model

Since the apps we examine don't specify authorization policies in their documentation, we define a minimal one for the purposes of our study. Our minimal policy contains just one confidentiality rule and one integrity rule:

Confidentiality An app may read a file only if it owns it or if the owner and the user have authorized the reading. Integrity An app may modify a file only if it owns it or if the owner and the user have authorized the modification.

The policy can be enforced by many authorization mechanisms, including those listed in Section 2.

Regarding the attacker model, we first assume that the Android protection mechanisms are enforced according to their specification (i.e. the phone isn't "rooted", giving arbitrary power to an app). Next, we make the same assumption that Android does regarding app isolation: that apps are mutually suspicious. The attacker is assumed to be (1) installed on the phone, (2) capable of performing polynomial time programmatic tasks, and (3) in possession of a set of authorization-related permissions that seem may seem innocuous: READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE (51% of popular applications request it), READ_LOGS (6% of popular applications request it6 ), and INTERNET (77% of popular applications request it) [START_REF] Chia | Is this app safe? A large scale study on application permissions and risk signals[END_REF]. Any series of actions which such an attacker can take to contravene the authorization policy defined above is an attack.

Study of Sharing Applications

We now consider four popular Android applications which enforce authorization using the mechanisms defined in Section 2. The applications are chosen because they illustrate the use of a variety of mechanisms and are representative of classes of apps.

GMail downloads attachments to its private storage area and manages them via a content provider which is protected by custom permissions READ_GMAIL and WRITE_GMAIL. The permissions are signature level permissions, so only Google applications can request them [START_REF] Bray | Recent Android app update prevents third-party apps from using com[END_REF]. GMail allows the user to open an attachment using an outside document viewer by sending an intent containing a URI read permission. Applications which behave similar to GMail include the built in Android Email application and K-9 Mail.

Attacks: The use of a protected content provider ensures that only applications sent the URI permission can read the file. However, some recipient viewers immediately make a copy of any file sent to them by URI. For example, Adobe Reader copies any file it shows to the SD card in the downloads directory, making it readable by an attacker (confidentiality).

Yahoo! Mail has a content provider which is protected by a custom signature permission (com.yahoo.mobile.client.android.permissions.YAHOO_INTER_ APP). Yahoo! lets the user open attachments using URI permissions, just like GMail. However, downloaded attachments are stored on the SD card, so they are readable by any application with READ_EXTERNAL_STORAGE. The MailDroid (groups.google.com/group/maildroid) application behaves similarly.

Attacks: Since Yahoo! stores all downloaded attachments on the SD card, an attacker can read them (confidentiality). The application does not check for downloaded file integrity, so once on the SD card they may be modified by an attacker as well (integrity).

Google Drive offers two mechanisms for sharing files on the phone.

First, the on-phone app lists the files and directories on the cloud and downloads one when the user requests to view or share it. Files can't be updated on the phone. A downloaded file is placed in a new, randomly named directory in a document cache directory located in Google Drive's private storage (/data/data/com.google.android.apps.docs/cache/). The new directory contains just one file and is world readable and executable. The file is made world readable and all the directories above the randomly named directory are world executable, letting any app open the file, but not list the directory names under cache. The file path is sent to the target as the data field of an intent.

Second, apps can access Google Drive via a web service interface which is protected by SSL and OAuth 2.0. An app receives an API identifier which it can use to obtain file read and write tokens. An app can download files via their names or identifiers and send updates back over the web.

Attacks: With respect to the on-phone app, the directory path is a secret since any application which knows it can open the file. Activity Manager, however, prints the data fields of all intents to the log, so the path is printed as well. An attacker which has READ_LOGS permission can discover the path and read the file (confidentiality).

Dropbox lists the files and directories in the cloud and downloads them on demand. The files are stored on the SD card in a directory called scratch. When sharing a file, it is first stored in the scratch directory and then the path and filename are sent via an intent. Downloaded files can be opened for reading and editing, but are not checked for integrity after downloading. When opening a file, the user chooses which file viewer to use; if the viewer saves a new version, it is uploaded to the cloud. Saves are monitored until the authorized viewer closes or loses focus. Dropbox ignores saves by other applications, even when an authorized viewer is working.

When sharing a file for attachment to an email, the file is uploaded (if necessary) and a web URL is provided in the intent as an extra. The URL provides read only access to the file and includes a random string to make guessing harder.

Attacks: Since downloaded files are stored on the SD card, they are readable by an attacker (confidentiality). Unauthorized saves are not automatically uploaded to the cloud, but since there is no integrity check, an attacker can tamper with a file and subsequent views of the file on the phone will show the tampered version. If a viewer unknowingly saves a tampered version, the attacker's modifications will reach the cloud (integrity).

Discussion

Our study of four popular and well-regarded applications illustrates the difficulty in getting even a simple authorization policy right. Many applications place sensitive data on public external storage. Some use unguessable directory names in private storage, but these names may leak into the shared system log. Still others may themselves correctly implement access control, but may be let down by the applications with which they share files.

Simple technical tricks aren't sufficient against a dedicated adversary. Wuala (wuala.com) tries to place shared files on the SD card for only a few seconds. However, due to Android's application life cycle, a malicious app can monitor the SD card and breach confidentiality during that gap. Boxcryptor (boxcryptor.com) encrypts files on the SD card and decrypts them just in time for the recipient. Such uses of encryption are limited by key management, that is, how to securely transfer a secret key to the recipient. Google Drive's example shows that transferring secret keys by intent is not always secure. Keys derived from passphrases are hard to keep secret, as shown by Belenko and Sklyarov [START_REF] Belenko | Secure Password Managers" and "Military-Grade Encryption" on Smartphones: Oh, Really?[END_REF]. Even if encryption keys are shared securely, file storage applications often misuse encryption and integrity algorithms and expose their plaintext to attackers [START_REF] Bhargavan | Web-based attacks on host-proof encrypted storage[END_REF].

We advocate a unified comprehensive approach to the implementation of application-level authorization. Rather than suggest point-fixes to prevent specific attacks, we show how to write formal models that precisely capture authorization policies and relevant parts of the execution environment. By automatically analyzing such models, we can both find attacks and gain confidence in the mechanisms used to enforce the policy.

Formal Model

As shown above, implementing even a minimal authorization policy requires an analysis of the authorization tools as well as the environment. Modeling can help such an analysis by including relevant parts of the Android authorization tools and the operating system. Developers can then create a model of their application, run it inside the Android model, and use automated tools to discover attacks. In this section we describe the building of such a model using ProVerif [START_REF] Blanchet | An efficient cryptographic protocol verifier based on Prolog rules[END_REF]. We show illustrative snippets of its parts: (a) the authorization policy, (b) the Android authorization tools, (c) parts of the Android OS, and (d) the sharing application. We then use the model to discover attacks in the models of the applications surveyed. ProVerif is well suited for our needs since (1) it enables the definition of authorization policies using Horn clauses and communication using the applied pi calculus; (2) it can model enforcement mechanisms that use secret and fresh file or path names and cryptography; and (3) it lets us analyze the models against an unbounded adversary.

Policy Language

The snippet below implements the minimal authorization policy from Section 3.1. It allows an app to read or write files only if it is the file's owner or if it receives authorization from the owner and the user. Lines 1-2 are a horn clause saying that if an application (a1) and a user (u) own a resource (r), then a1 is authorized to read r. Lines 3-4 enable another application (a2) to receive read authorization from the owners (a1 and u). The parallel write rules are omitted due to space considerations.

clauses forall u:Principal, a1:appid, a2:appid, r:resource; 1 owners(r, u, a1) -> readAuthorized(a1, r). Android Authorization Tools We implement the following Android authorization tools:

Permissions are included via a androidPerm type which is populated with permissions that can be granted by the user during installation.

URI Permissions are included via a uri type which refers to a file resource.

Resolution is modeled using a lookup table of uri and resource pairs. Private Storage is modeled by using a path type which refers to a location only accessible by the owner. If the path is declared world readable, writable, or executable, others can access it too. Fresh path names may be world readable, but only can be accessed if the requestor knows the path's name. SD Card is modeled as a file system process which enables the storage or retrieval of objects based on path and filename objects stored in a lookup table. Web Sharing is parallel to private storage, but without the need for setting path permissions.

The following snippet shows how file and log read permissions are handled (parallel file write clauses are elided). Lines 5-7 define the Android permission type, the permission to read the SD card (externalRead), and the permission to read the log (logRead). Lines 8-9 allow an application a to read a file with name f, path p, and any file and path permissions fp and pp if (1) a has the external read permission and (2) the file is on the SD card. Lines 10-11 allow an application a to read all files in its own private space (private(a)). Lines 12-14 allow an application a to read a file in another application o's private space if its path permissions (pp) are set to world executable (isWorldExecutable) and its file permissions (fp) are set to world readable (isWorldReadable). Line 15 allows an application a to read the log if it has logRead. Android OS Elements We include processes for the following authorization related Android processes:

File System process which enables applications to read, write, and list files on the SD card based on path and file name. The file system allows access to files in private storage by the owner and by others which know the path name if the permissions are set correctly. Content Provider process which enables applications to resolve URIs and thereby read or write files which they refer to.

Binder process which handles the granting of URI permissions, both from the owner and via delegation. Binder writes entries in the log. Log process which gives permission-based read and write access to the log. Permission Granting process which enables the user to grant permissions to processes.

The following snippet shows three parts of file system's code in the model. Lines 16-17 listen for file read requests (readFile) and check the application is registered. Lines 18-19 retrieve the file based on its location (l), path (p), and file name (f), check if a is able to read it, and return it to a if it is able. Lines 20-22 listen for requests to list the files in a directory path. Line 23 allows it if the path is world readable. Lines 24-27 allow an application to list all files on the SD card if the requestor has externalRead permission. Testing Application We implement a single process for each sharing application. The process registers the application, specifies how files are added, and specifies how files are shared with other applications ("open with").

The following snippet shows the Dropbox application. Line 28 defines the Dropbox application id as private (not known to the attacker initially). Line 29 is the header for the process. Lines 30-31 register Dropbox in the applications table (apps, definition elided) and publish the name of its private storage (private(dropbox)) and its web storage (web(dropbox)) by sending their values on the free channel pub (definitions of private, web, and pub are elided). This simulates an attacker knowing the application's root directory and web domain, but not knowing the paths below them where files are found. Lines 32-34 define a new file's contents (r), its file name f, and its path p; assigns ownership of the file to Dropbox (line 33, using the assume function which is elided); and inserts it in the files table (definition elided) on the web (web(dropbox)) where it stays until downloaded. The noPerms() terms are used to model file and path read, write, and execute permissions. Lines 35-40 model a user opening a file. Lines 35-36 receive an openWith command and download a file from Dropbox's web space (path p, path permissions pp, file name f, file permissions fp, file contents r). Line 37-38 select an application a and authorize it to read. Line 39 stores the file on the SD card in the files table with no explicit file or path permissions (noPerms). Line 40 returns the path and file name to the requestor by an explicit intent (explicitintent(a)). 1. Checks that proper authorization is reachable. ProVerif should show traces by which a user can properly authorize an app to read and write a file. 2. Checks that an attacker can't read or write files without proper authorization.

The first queries check that authorization is possible under the model. We expect to see traces of the sort: "The file is readable by the attacker if the user has sent a read URI permission to the attacker" or "A file in private storage is readable by the attacker if the application makes the file world readable, the path world executable, and sends an intent to the attacker with the path to file." Those represent valid authorization paths in the model. The second queries ensure that there are no other ways to read or write files aside from the authorization paths defined. If ProVerif finds any such paths, they are attacks. For example, ProVerif points out that line 39 above leaks the file to the attacker since it is allowed to read files on the SD card.

Authzoid Implementation

As shown above, the proper use of the authorization tools in Android requires careful design and analysis. In this section we describe our implementation of Authzoid, an app that lets file owners define authorization policies and then enforces them on their behalf. Authzoid uses the authorization tools explained in Section 2 to enable a wide variety of policies, including ones far richer than the minimal policy defined in Section 3.1. Authzoid is useful as a sample implementation of proper authorization, fixing the mistakes of the apps discussed above and can be useful as a starting point for developers who want to get authorization right. Its source code can be found at: http://prosecco.gforge.inria. fr/Essos/pv/.

Authzoid offers three application-facing interfaces: file submission, policy definition, and file retrieval. It manages file versions and authorization checks internally.

Submission Interface Applications can submit files to Authzoid for storage using an intent with a custom action. The intent can contain a file to share or a content URI to resolve. Files can be submitted as new or as updates to existing files.

If submitted as new, Authzoid retrieves the name of the submitting application via the Android API and stores it in its private storage area. A private database indexes the files by their original file name or URI and submitting application. The new file is assigned a new version number which is returned to the submitter. The submitter may optionally include a permission as a string extra. If included, any application with the given permission may later read or modify the file (see below).

If submitted as an update, the file must be accompanied by the name of the owner, the file's original path and file name, and a version number which indicates the last version of the file the submitter saw. Authzoid first checks if the submitter is authorized to update the file (see below). If not, an authorization failure message is returned. If the update is authorized, but the version number submitted is smaller than the current version number in the database, the update is rejected with an explanatory message. Otherwise, the file is copied in to private storage and the database is updated. Authzoid generates a new version number which it stores in the database and sends it back to the submitter.

Policy Definition By default, only the application which submitted a file (its owner) can read or write it. Authzoid enables owners to share the file via URI permissions, by adding another app to the file's read and write access control list, or by retrieving a read-only randomized path name (similar to Google Drive). Groups of apps can be added by setting a permission on the file; then any application with the permission can read or write the file.

Retrieval Interface An app can request a file from Authzoid by sending an intent with owner's name, the file's original path, and name. For each request, Authzoid queries its access control matrix to see if the requestor is authorized to read the file. If the read is approved, Authzoid checks if a copy of the latest version of the file is already in the cache. If not, it generates a new directory under its private filecache directory with a 128-bit random name and puts a copy of the file in it. The file and random directory are set to be world readable and the directory is set to be world executable. Whether new or existing, the full file path of the file are returned to the requestor using an intent with the full path in an extra.

When an application resolves a URI using Authzoid's content provider, the content provider makes a new copy of the file, opens a new file descriptor on it, deletes the file using the Java file API, and then returns the file descriptor. This prevents read/read conflicts on the file. Since the file descriptor acts as a hard link, the Android OS will preserve the contents of the file until the recipient closes the file descriptor or is killed.

Folder listings can be requested by sending the owner's name and the path via an intent. Authzoid checks its access control matrix to see if the requestor is the owner or authorized to list the directory. If authorized, a listing of all files and directories in and under the given directory is sent back via an intent as a string array extra.

Authzoid is the first Android app that provides a unified authorization service enabling file sharing between Android apps. Using ProVerif, we verified that Authzoid is secure against the class of attacks captured in our formal model. This should not be interpreted as a formal theorem however, since our model of both Android is abstract and incomplete, and may hide other attacks. Still, our analysis presents a first step towards formal security analysis for Android applications. Our models are public and may be extended for more sophisticated analysis.

Related Work

Research on Android's security infrastructure includes studies on how permissions are enforced [START_REF] Felt | Android permissions demystified[END_REF], used [START_REF] Barrera | A methodology for empirical analysis of permission-based security models and its application to android[END_REF], and misused or attacked [START_REF] Chia | Is this app safe? A large scale study on application permissions and risk signals[END_REF][START_REF] Davi | Privilege escalation attacks on android[END_REF][START_REF] Felt | Permission re-delegation: attacks and defenses[END_REF][START_REF] Hornyack | These aren't the droids you're looking for: retrofitting android to protect data from imperious applications[END_REF]. Some try to secure Android applications against attackers by performing static or dynamic analysis of apps (ex. [START_REF] Enck | On lightweight mobile phone application certification[END_REF][START_REF] Chan | Droidchecker: analyzing android applications for capability leak[END_REF][START_REF] Fuchs | SCanDroid: Automated security certification of android applications[END_REF]). Xu, et al. [START_REF] Xu | Aurasium: practical policy enforcement for android applications[END_REF] developed Aurasium, a tool that uses static analysis and code injection to detect or prevent privilege escalation attacks. Like Authzoid, Aurasium does not require modifications to the operating system. Conti, et al. [START_REF] Conti | Crepe: context-related policy enforcement for android[END_REF] developed CRePE, a system capable of enforcing rule based context aware security policies. Naumann, et al. [START_REF] Nauman | Apex: extending android permission model and enforcement with user-defined runtime constraints[END_REF] extended Android permission with custom user defined constraints. None of the above work includes formal analysis or verification.

Research on formalization of the Android stack and API includes Chaudhuri [START_REF] Chaudhuri | Language-based security on android[END_REF] who gave a formal model of a subset of the Android communication system; Enck, et al. [START_REF] Enck | Taintdroid: an information-flow tracking system for realtime privacy monitoring on smartphones[END_REF] who developed TaintDroid to track the flow of sensitive information between Android apps (extended by Shreckling, et al. [START_REF] Schreckling | Kynoid: real-time enforcement of fine-grained, user-defined, and data-centric security policies for android[END_REF] with more complicated, dynamic run time policies); and Armando, et al. [START_REF] Armando | Formal modeling and reasoning about the android security framework[END_REF] who presented a more complete model of the Android middleware using types.

With respect to formalizations for secure sharing of resources, Blanchet and Chaudhuri [START_REF] Blanchet | Automated formal analysis of a protocol for secure file sharing on untrusted storage[END_REF] developed a formally verified protocol for secure file sharing on untrusted storage (a tool which could be used to secure Android's SD card) and Fragkaki, et al. [START_REF] Fragkaki | Modeling and enhancing android's permission system[END_REF] gave formal typing rules to explain Android's security model. Similar to our work, Fragkaki et al. described Sorbet, a modification to Android which enforces secrecy and integrity properties written by app developers. In contrast, Authzoid is developed to enable the easy specification of authorization policies and relies upon existing Android mechanisms without requiring changes to the operating system. Since many Android apps are distributed free and make money from in-app ads, work has been done to determine how ad libraries operate and whether they pose privacy or authorization risks. Dietz, et al. [START_REF] Dietz | Quire: Lightweight provenance for smart phone operating systems[END_REF] developed Quire which enabled advertisers to prevent app based ad fraud. Stevens, et al. [START_REF] Stevens | Investigating user privacy in android ad libraries[END_REF] investigated the behavior of thirteen ad libraries and showed how their requirements cause app developers to request more permissions than necessary (permission bloat). As a remedy to permission bloat, Shekhar, et al. [START_REF] Shekhar | Adsplit: separating smartphone advertising from applications[END_REF] implemented AdSplit, a mechanism to separate ad libraries from individual apps.

Conclusion

Many Android apps attempt to enforce authorization policies for sharing resources, but fail due to misuse of the Android authorization tools or due to actions by external entities. We can discover authorization attacks by using ProVerif to model a relevant subset of the Android authorization tools and environment and use it to examine the behavior of sharing applications. We also describe Authzoid, an application which lets app developers specify authorization policies for sharing and enforces them using built-in Android tools. Future extensions to Authzoid include work on making an encrypted cache on the SD card and enabling it to proxy OAuth based web sharing.

2

  clauses forall u:Principal, a1:appid, a2:appid, r:resource; 3 owners(r, u, a1) && userAuthorizedRead(u, a2, r) -> readAuthorized(a2, r).

4

 4

7 clauses

 7 forall a:appid, l:location, p:path, f:filename, pp:filePerms, fp:filePerms; 8 hasPermission(a, externalRead()) -> canReadFile(a, sdcard(), p, pp, f, fp).

9

  clauses forall a:appid, l:location, p:path, f:filename, pp:filePerms, fp:filePerms; 10 canReadFile(a, private(a), p, pp, f, fp). 11 clauses forall o:appid, a:appid, p:path, f:filename, pp:filePerms, fp:filePerms; 12 isWorldExecutable(pp) && isWorldReadable(fp) -> 13 canReadFile(a, private(o), p, pp, f, fp).

14 clauses

 14 forall a:appid; hasPermission(a, logRead()) -> canReadLog(a).

15

 15

23 |

 23 let FileSystem() = (!in (filesystem,readFile(a, l, p, f)); 16 get apps(=a) in 17 get files(=l, =p, pp, =f, fp, r) in 18 if canReadFile(a, l, p, pp, f, fp) then out(return(a), r)) 19 | (!in (filesystem,listFile(a, l, p)); 20 get apps(=a) in 21 get files(=l, =p, pp, f, fp, r) in 22 if isWorldReadable(pp) then out (return(a), f)) (!in (filesystem,listSDCard(a)); 24 get apps(=a) in 25 get files(=sdcard(), p, pp, f, fp, r) in 26 if hasPermission(a, externalRead()) then out (return(a), (p, f))).

  free dropbox : appid [private].

28 let 29 (

 2829 Dropbox(u:Principal) = insert apps(dropbox); 30 out (pub, (private(dropbox), web(dropbox)))) 31 | (!new r:resource; new f:filename; new p:path; 32 if assume(owners(r, u, dropbox)) then 33 insert files(web(dropbox), p, noPerms(), f, noPerms(), r)) 34 | (!in (openWith, ()); 35 get files(=web(dropbox), p, pp, f, fp, r) in 36 get apps(a) in 37 if assume(userAuthorizedRead(user, a, r)) then 38 insert files(sdcard(), p, noPerms(), f, noPerms(), r); (*readable by attacker*) 39 out (explicitintent(a), (p, f))). 40 Discovery of Attacks By combining the testing application's model with the environment and authorization code, we can check two types of queries in ProVerif:

Changed to signature/system/development permission in API level 16.

The most popular PDF reader on Google Play as of Oct 2012.

As of Oct 2011, READ_LOGS was the ninth most popular dangerous Android permission requested. In API level 16, it was converted to a system/signature/development permission, so access to it on the most recent devices is significantly reduced.


Paula Vásquez Lezama

Paula Vásquez

Lezama Disaster

DISASTER AND UNCERTAINTIES IN THE CONTEXT OF VENEZUELA'S OIL CRISIS

Keywords:

d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

OF THE EXPLOSION AT THE AMUAY OIL REFINERY

On August 25, 2012, the Amuay oil refinery in northwestern Venezuela suffered an explosion. This unprecedented accident in the national oil industry killed 48 people and injured 156. In this study, we have adopted a political anthropology approach, in which natural and industrial disaster issues are posited as part and parcel of a nation's history. Our purpose is to examine the relation between the oil industry, the changes that took place within the state during the Venezuelan "Bolivarian revolution," (1) collective attitudes towards disaster anticipation, and social representations of uncertainties and insecurity.

Our study of the Amuay explosion and blaze is part of an analytical reconstruction of the oil policies of the Chavez (1999Chavez ( -2013) ) and succeeding Maduro administra-tions. After the new majority won the parliamentary elections of December 6, 2015, it set about closely examining the financial statements and condition of facilities of the state-owned company Petróleos de Venezuela (PDVSA). The new representatives questioned the veracity of the company's financial statements and reports. The country's economy came under serious threat and lapsed into crisis, and the growth model championed by the late President Hugo Chavez collapsed.

Granted, the crisis in that model, which relied heavily on oil revenue, was aggravated by the 2014 drop in the price of the barrel, but a revision of economic data shows that the end of the last oil boom (2006)(2007)(2008)(2009)(2010)(2011)(2012)(2013)(2014) is not the main culprit. The citizens of Venezuela are confronted with highly unusual situations in their daily lives. During our fieldwork in Caracas, Coro and Punto Fijo (about 600 kilometers west of Caracas) in the summer of 2015, we noted the harsh effects of an inflation rate nearing 120 percent and causing increased shortages of basic foodstuffs and medicine. And the economic outlook for 2016 is no less grim.

Our investigation spans issues ranging from the uncertainties of the victims' families as to the safety conditions of the site to the multiplier effects underscored by the international press -plummeting national production and a verified drop in the price of the barrel. It is a multi-level study of the way in which these families express their uncertainties based on a multi-sited ethnographic study and participant observation in the area affected by the refinery explosion of 2012.

BACKGROUND AND IMPACT OF THE OIL INDUSTRY CRISIS

Venezuela is one of the oldest oil-producing countries and a founding nation of OPEC. Its modernity is intrinsically linked to hydrocarbon exports and the effects of their revenue on all areas of social life. Upon his election into office in 1998, Chavez convened a Constituent Assembly. The ensuing revamping of the nation the following year led to a radical change in the status of PDVSA. Between the nationalization of the oil industry in 1975 and the general strike of October 2002, PDVSA was a self-sustaining public company run on the principle of "technocratic merit." In 2002, however, it came entirely under the control of the executive branch and started providing financial support for the government's policies.

(1) See Paula Vasquez Lezama, Le Chavisme: un militarisme compassionnel (Paris: Editions de la Fondation de la Maison des sciences de l'homme, 2014).

Prior to 1998, PDVSA's autonomy was guaranteed by a legal framework allowing it to set goals concerning both the upstream (exploration and production) and downstream (distribution) sectors. The state-owned oil company was then a powerful structure enjoying relative independence from the government and sometimes described as "a state within the state." (2) Between 1958 and 1998, the Venezuelan growth model was based on "sowing the oil," that is, on reinvesting oil rents in other sectors, thereby diversifying the economy. It was the model of a rentier, "magical," state, to use anthropologist Fernando Coronil's formula (3). The "Bolivarian revolution" put an end to a reinvestment pattern that allowed for direct redistribution to the very poor. As a result, the state's dependence on oil revenue increased markedly.

But Venezuela's oil production has been declining since 2002, and exploitation has reached its lowest level ever in fifteen years. During Chavez's first term in office, PDVSA produced 3.5 million barrels per day, but by 2013, it had dropped to 2.6 million. On the other hand, between 1998 and 2014, the company's staff tripled in size, passing from 42,000 to 111,000, an increase due to a clientelist employment policy conducted to the detriment of maintenance, particularly in refineries.

The policies conceived and implemented by President Chavez are currently under challenge, notably because of PDVSA's present situation and arrangements with Cuba (4) and China (5). The geopolitical context deriving from chavista oil diplomacy has created uncertainty in the entire region as to the future of oil export agreements not only with Cuba, but with Haiti and Nicaragua. Oil being the driving force behind a whole range of national and regional initiatives, these agreements are untenable given the present state of the oil industry, national economy, and price of the barrel.

On April 11, 2002, an attempted coup against Chavez failed. It was followed by a tug-of-war between the opposition, which controlled the commercial sector and private companies, PDVSA and the government. After the "oil lockout" (paro general petrolero indefinido), which lasted exactly two months (from December 2, 2002 to February 2, 2003), the government regained control of the company by totally renewing the executive staff. The process was ruthless and involved drastic measures in areas where executives had no room for negotiation and were given

(2) Asdrubal Baptista and Bernardo Mommer, El petróleo en el pensamiento económico venezolano (Caracas: Ediciones IESA, 1992).

(3) Fernando Coronil, The Magical State. Nature, Money, and Modernity in Venezuela (Chicago: The University of Chicago Press, 1997).

(4) Since 2000, Venezuela has delivered between 50,000 and 100,000 barrels of oil per day to Cuba.

(5) Since 2007, the government of the People's Republic of China has loaned 36 billion dollars to Venezuela. Part of the loan is to be repaid in oil through the delivery of 270,000 barrels per day.

no other option than "Take it or leave it." For example, on December 26, 2002, during the Sunday television show Alô Présidente, Chavez dismissed PDVSA's board of directors and fired 90 executives as well as 18,756 skilled workers.

WHAT COLOR IS THE SMOKE COMING OUT OF THE FLARES ?

The August 2012 disaster at Amuay, the second largest refinery in the world, has come to symbolize the inadequacies of Venezuela's oil industry. The government ascribed the accident to acts of sabotage. However, several accidents on PDVSA sites had occurred prior to that date. In February 2012, an important oil spill fouled the Guarapiche river in Monagas state in eastern Venezuela, depriving the city of Maturin of its water supply for months. And a series of oil spills on the Falcon Coast have occurred since the Amuay explosion. Analysis of documents pertaining to the accident has revealed severe technical maintenance problems, illegal attribution of maintenance contracts and insufficient personnel training.

How do the transformations by the state of one of its pillars, the oil industry, find an echo in the discourse, practices and political uncertainties of the residents of an "oil city?" Our fieldwork took place during the summer of 2015 in Punto Fijo, a city located in the vicinity of the refinery, and Coro, Falcon state. It followed three lines of enquiry.

The first line concerned the controversy over the technical origin of the explosion.

The interviews we carried out show that supporting either of two theses -"sabotage organized by the opposition" or "maintenance neglect" -implied a political positioning on the population's part in a context dominated by political violence. We interviewed experts, eyewitnesses and managers of plants located in the vicinity of the disaster area in order to reconstruct the controversy over the causes and consequences of the accident. It must be noted that in Venezuela, analysis of a topic such as this one is plagued by a dominant provision whereby each and every one must take sides. The investigation very soon turned out to be a real minefield. The official media discourse on oil was permeated with conspiracy theories. Our work currently consists in understanding PDVSA management's standpoint and arguments and including them in the study of the future of Chavez's political project.

The second line addressed the emergency response to the explosion by trailing the whereabouts of casualties and serious burn victims. The best place for conducting this part of the investigation was the Punto Fijo city hospital since the management of the disaster had been totally censored by the Chavez administration and journalists had been barred from accessing the site and interviewing emergency practitioners in the hospital. The news media had been quarantined from the area affected by the shockwave and fire and from the hospital morgue. Therefore, the data that we have gathered is sensitive as interviewees fear reprisals.

The third line dealt with the daily lives of the residents of Punto Fijo and their attitude to the oil refinery that supported their livelihood: they were directly or indirectly employed by it or acted as suppliers. The presence of the refinery and its equipments presented a growing threat, with defective alarm systems, a faulty evacuation plan from the security perimeter, repeated "events" following the 2012 accident, and absence of explanations from official sources as to the causes (and consequences) of these recurring accidents.

Participant observation in those neighborhoods provided very rich data on life in a risk area where authorities kept silent on the state of equipments and anxietyprovoking rumors on what was going on inside the refinery circulated. Punto Fijo residents carefully watched the color of the smoke coming out of the flares. A large plume of black smoke was a sign of equipment failure. Any unusual noise or smell could provoke anxiety. The refinery loomed mysterious and threatening and was perceived as tantamount to an unpredictable natural hazard. Noises, smells, and unusual machinery and personnel activity generated rumors and were routinely interpreted and reinterpreted as warning signs of impending doom.

The events lived through by the population living in the neighborhood of the refinery and by the victims of the explosion point to the limits of the political model installed by Chavez more eloquently than polarized diatribes. These families did not receive compensation from PDVSA and were not offered relocation -those who were refused to leave these high-risk areas. Their experiences and testimonies deserve analysis because they can help us understand how the Amuay oil refinery can sustain life or take it away.

LaboratoryofExcellenceTEPSIS,96BDRaspail75006Paris,https://tepsis.hypotheses.org


Mathieu Jeannin

Pamela Rueda-Fonseca

Edith Bellet-Amalric

Kuntheak Kheng

Gilles Nogues

Deterministic radiative coupling between plasmonic nanoantennas and semiconducting nanowire quantum dots

Keywords: semiconductor, nanowire, plasmonics, nanoantenna, nanofabrication, cathodoluminescence PACS numbers: 42.79.-e, 78.67.-n, 42.82.Fv

Introduction

Recent progress in semiconductor growth research now allows for fabrication of nanowires (NWs) structures which are of great interest for their high crystalline quality, strain free character and practical geometry. A key step towards realization of nanooptical circuits and applications relies on the coupling of single NWs with other structures, like photonic crystal cavities [1] or plasmonic nanoantennas [2,3,4,5] (NAs). To better use the advantages and the versatility of NWs, it is now necessary to adapt previous studies on self-assembled or colloidal quantum dots (QDs) to their NW counterparts. While numerous results have been obtained in the coupling of selfassembled [6,7,8,9,10] and colloidal [11,12] QDs with plasmonic nanostructures, all the existing studies on control of the optical properties of nanowire quantum dots (NWQDs) rely on a photonic approach, using the nanowire itself as an antenna [13,14,15]. Following previous work in our group [8] on droplet epitaxy QDs, we show how combining cathodoluminescence (CL) with standard e-beam lithography technique allows to fabricate at will plasmonic NAs in the vicinity of II-VI NWQDs emitting around 620 nm. Both systems are initially fully characterized using CL for the antennas and micro-photoluminescence (µPL) and time-resolved spectroscopy for the emitters. Previous studies have made use of morphological criteria to detect nanoemitters, using scanning electron microscopy (SEM) or atomic force microscopy [7]. In contrast, our method has the advantage of allowing localization of embedded structures undetectable with the previous methods.

Nanowire quantum dot properties

Our nanoemitters are single (Cd,Mn)Te QDs (Mn fraction ≈ 5%) inserted inside ZnTe/(Zn,Mg)Te core/shell nanowires [figure 1 (a)]. The NWs are grown by molecular beam epitaxy on a (111)B GaAs substrate covered by a 500 nm thick buffer layer of ZnTe [16,17]. Dewetted gold droplets are used as catalysts, and temperature variations allow to favor different growth mechanisms resulting in the final heterostructure. The core growth is both longitudinal and lateral, leading to the conical aspect of the nanowire, with a core diameter of 20 nm at the top to ≈200 nm at the base, and a 20 nm thick shell. The QD emission is measured by confocal µPL spectroscopy. It features a main emission peak around 620 nm, blue-shifted by 150 nm compared to the exciton transition in bulk CdTe [18] due to the confinement and the strain induced by the surrounding shell [19]. It is significantly broadened (FWHM 10 nm) by the presence of the magnetic Mn atoms creating a fluctuating magnetic field inside the QD, randomly shifting the exciton line in time by Zeeman effect [START_REF] Stepanov | Magneto-optical spectroscopy of magnetic semiconductor nanostructures[END_REF] [figure 1 (b)]. Amongst all the studied NWs, the central emission wavelength ranges from 605 to 630 nm.

NWs are detached from their growth substrate and dispersed onto a host substrate for optical studies. The host is a Si substrate pre-patterned by optical lithography and dry etching to fabricate coarse localization marks. It is covered by a 100 nm thick Au layer deposited by e-gun evaporation and a 250 nm thick Al 2 O 3 spacing layer by atomic layer deposition. The mirror and the spacer thickness are designed to give constructive interferences between the light directly emitted from the QD and the light reflected by the mirror in order to maximize luminescence collection. NWs are finally dispersed by mechanical contact between the host and growth substrates. A first selection of NWs is performed using CL at 5 K [8,16]. The luminescence from the QD is spectrally filtered and detected by an avalanche photodiode (APD). CL imaging of the emission profile at the QD luminescence wavelength is obtained for a set of NWs. To avoid spurious emission from exciton trapped in defects at the base of the NWs, we conserve only structures presenting a well localized emission in the top half of the conical NW and having the typical spectral structure of figure 1 (b). The selected QDs are then fully characterized by µPL spectroscopy at 5 K. The NWs are excited at 447 nm by a frequency doubled, ps pulsed Ti:Sapphire. Time-resolved measurements are performed at very low pumping power, well below saturation of the QD, with a spectral integration bandwidth of 2 nm to ensure that we only detect the excitonic transition, resulting in a monoexponential time trace. They show decay times ranging from 0.2 to 1.18 ns [figure 1 (c)]. The average lifetime (τ = 0.68 ns) is about five times longer than for self-assembled CdTe/ZnTe QDs [START_REF] Man | [END_REF]. In addition, the emission from the QD is linearly polarized in a direction parallel to the NW axis in 70% of the cases, and orthogonal in all the others. The average degree of linear polarization is 0.7 ± 0.2. These optical properties can be explained by the very small energy difference between the valence bands of CdTe and ZnTe [START_REF] Stepanov | Magneto-optical spectroscopy of magnetic semiconductor nanostructures[END_REF]. The resulting nature of the ground hole state strongly depends on additional energy shifts induced by strain or QD aspect ratio [22,19]. In our case, the orbital hole wavefunction is probably poorly confined inside the QD, resulting in low electron-hole wavefunction overlap and thus long radiative decay time. We note that the measured decay rate 1/τ = γ r + γ nr , where γ r (resp. γ nr ) is the radiative (resp. non-radiative) decay rate, might be limited by non-radiative processes. Furthermore, a large variability from dot to dot strongly mixes the light-and heavyhole bands, explaining the polarization results. This variability is not detrimental to our study as we compare a complete set of optical properties on the one and same NW before and after antenna fabrication.

Nanoantenna characterization

Au nanoantennas are fabricated on the host substrate, in a region empty of NWs. They consist in single rectangles of 70 nm fixed width, as sketched in figure 2 (a). Their length L varies from 85 to 140 nm. They are fabricated by electron-beam lithography on a 200 nm thick Poly(methyl methacrylate) (PMMA) bi-layer resist, using PMMA with molecular weights of 50 kDa and 950 kDa to create a mechanical mask with the resist. 35 nm of Au is deposited on the sample by e-gun evaporation. N-methyl-2-pyrrolidone (NMP) lift-off with 80 • C heating is finally performed to remove the resist.

The antennas are characterized using CL at room temperature [23,24]. The CL spectrum of each antenna is obtained by raster-scanning the electron beam over its surface. It presents a large peak at a fixed wavelength around 580 nm and a second resonance at lower energy. CL spectra for all the antenna are presented in figure 2 (b), revealing that the second resonance red-shifts with increasing antenna length. We note that the optimization of the Al 2 O 3 spacer thickness in order to increase the collected signal at 620 nm results in destructive interferences for the collected light in the 700 to 800 nm wavelength range, decreasing the detection contrast in this spectral region. Further information is obtained by imaging the plasmon local density of states [23] (LDOS). It is reconstructed by slowly scanning the electron beam over the antenna and collecting the CL emission as a function of the beam position filtered in a 100 nm spectral window around the resonance energy on an APD. This spectral integration bandwidth is chosen to maximize the collected signal from the antenna. For L ≥110 nm, it is smaller than the energy separation between two consecutive modes so that only a single resonance contributes to the LDOS image. The LDOS of the red-shifting resonance [figure 2 (c be extracted from figure 2 (b)(blue squares). On the contrary, the LDOS at 580 nm [figure 2 (d)] shows no precise spatial structure at any length. We have fabricated nanoantennas of different shapes, sizes and spacer thicknesses and observed that it is always present. The energy of its maximum only depends on the Al 2 O 3 spacer thickness (see Supplementary Material [25]). We attribute this peak to the scattering by the NA of the continuum of surface plasmon polariton modes sustained by the Au/Al 2 O 3 /air multilayer system. LDOS evaluation based on numerical calculations of the surface plasmon polariton dispersion relation [26] show that at this energy a lot of lossy modes contribute to the signal. We note that we use here a 250 nm thick spacer for which no significant coupling occurs between the antenna and the metal film, which simply acts as a mirror to reflect emitted and scattered light towards the collection objective.

To determine the relevant dimensions for enhancing emission processes at the QD wavelength, we plot a cut of figure 2 (b) at λ QD = 620 nm [green solid line, figure 2 (e)]. It predicts an increase in scattering efficiency for an antenna length around 95 nm due to the contribution of the dipolar mode. It also predicts an enhancement for lengths above 140 nm. This enhancement comes from the onset of a higher order mode theoretically predicted to appear at this length [26,27]. We note however that for the target coupled NW-NA system, the presence of the very high refractive index nanowire (n ZnTe ≈ 3) in the near-field of the antenna significantly modifies its plasmonic properties. Hence a red-shift in the plasmon dispersion relation curve is expected, and the enhancement peaks observed in figure 2 (e) will occur for smaller antenna lengths. times are limited to a few seconds to limit mechanical and electrostatic drifts. We fit the QD emission peak with a bi-dimensional Gaussian profile and superimpose it to the corresponding SEM image. It allows to precisely localize the QD inside the NW in the frame defined by the fine alignment marks. NAs are then fabricated with the same process as the previously characterized antennas. Before insulation of the resist, a final alignment step is performed onto the fine marks under the resist. The antennas have a fixed width w = 70 nm and a variable length L from 50 to 140 nm. This range is based on the previous CL results and takes into account the shift due to the presence of the NW. The antenna sides of length L are parallel to the measured polarization direction of the QD emission. We aim at having an antenna to NW gap equal to zero. SEM images reveal an average gap of 12 nm±50 nm, thus some antennas are on top of the NW. The final error of 50 nm has different sources. Alignment of the lithography setup has a typical error of 20 nm but is degraded in our case due to poor contrast of the fine alignment marks image under the resist. We evaluate the thermal, mechanical and electrostatic drifts error during CL at low temperature to 30 nm. We note that the NW core and shell are already thick (≈50 nm at the QD position). The resulting QD to antenna distance ranges from 50 to 110 nm. This distance is always large enough to prevent luminescence quenching, and the variations due to the positioning error only have a moderate effect on the NA to QD coupling [28].

Photoluminescence observations

The coupled QD-NAs systems are characterized using µPL spectroscopy with a pulsed excitation laser at a wavelength of 447 nm. Figure 4 (a) compares the integrated QD emitted intensity as a function of the exciting laser power P exc before and after antenna fabrication for L = 63 nm. The PL intensity first increases with the excitation power and then saturates because of the complete occupation of the discrete excitonic state in the QD. For a same excitation power one clearly sees a much higher collected signal in presence of the NA. Similar measurements on other QDs present on the substrate which have experienced the same process except the final antenna fabrication show no change in their properties. Previous studies revealed modification of the luminescence collection by redirection of light by the antenna [5,6,8]. We have carried out Fourier plane microscopy by imaging the back focal plane of the microscope objective in the µPL setup (see supplementary material [25]) to observe the radiation diagram of the NWQDs [29], and we did not observed significant change in the radiation pattern after antenna fabrication. Clearly, the higher PL intensity we measure is not due to the redirection of light by the antennas. Additional information is provided by measurements of the exciton lifetime before (τ 0 ) and after (τ N A ) antenna fabrication under the same excitation conditions. We observe no significant change, with an average ratio τ N A /τ 0 = 1.1 ± 0.2 (see Supplementary Materials [25]).

To better analyse the effect of the antennas, we evaluate the saturation intensity I s at high excitation power, and the slope at the origin g of the power-dependent µPL

0 1 2 3 4 5 0 1 2 3 I ¢ i£¤¥¦¥¤ §¨ §o© ©£ s t s s ! " # s E $ ) g£ ex% & ' (a)
x( )01200a curve. The ratio of I s before and after antenna fabrication is plotted as a function of antenna length in figure 4 (b), showing a net increase after NA fabrication. As shown in figure 4 (c), we also observe a greater increase in the slope g after NA fabrication.

Discussion

Assuming that we only detect the excitonic transition and considering that the nanowire excitation is done with a pulsed laser, the saturation intensity I s is equal to f × γ r /(γ r + γ nr ) × α coll , where f is the laser repetition rate, Y = γ r /(γ r + γ nr ) is the quantum yield and α coll is the fraction of the emitted power collected by the microscope objective. As we measure no change in the radiation diagram after NA fabrication, it is reasonable to assume that α coll is unperturbed. As a consequence the enhancement observed in figure 4 (b) is directly related to an increase in the quantum yield Y . This enhancement is found to be moderate for antennas with a length greater than 60 nm but stronger for the smallest antenna, up to a factor 2.5. As expected from section 3, it occurs for shorter antennas than the determined resonant length from figure 2 (e). Moreover since the QD response at saturation is independent of the excitation power, the change of I s after antenna fabrication is not due to an increase of the absorption inside the NW. Nevertheless, CL spectra of the NAs at λ exc =447 nm show that there is still a measurable LDOS at this energy that can modify the absorption of the excitation laser inside the NW (see Supplementary Material [25]). The main contribution to this LDOS comes from the fixed resonance observed in Figure 2 and does not depend on the antenna length. The change of the absorption can be retrieved by analyzing the slope at the origin g. In the limit of low excitation regime, g is expected to be proportional to Y × α abs × α coll , where α abs is the fraction of power absorbed in the NW. As α coll remains unchanged after NA fabrication, the ratio (g/g 0 )/(I s /I s0 ) directly gives the change in α abs . The comparison of figures 4 (b) and (c) shows that the absorption in the NW is enhanced by a factor 2.2±1.1 over the whole antenna length range. Further illustration of the respective changes in I s and g are presented in the Supplementary Materials [25] with two other power-dependent µPL curves. Our main conclusion is that, for the shorter antenna lengths, enhanced NW absorption and improvement of the quantum yield contribute equally at ∼50% to the four-fold increase of g that we observe.

Finally, lifetime measurements show that there is no change of the total decay rate γ r +γ nr . This is an indication that the total decay rate is dominated by the non-radiative term γ nr and is moderately affected by a change in γ r . The increase in Y that we observe is therefore essentially due to an increase of the radiative rate γ r of the QD because of the coupling to the NA.

Conclusion

In conclusion, we demonstrated deterministic coupling between single semiconducting nanowire quantum dots and plasmonic nanoantennas using CL and electron-beam lithography with a precision of 50 nm. Our method has the advantage of relying only on the luminescence of the emitters for their precise localization. It also grants full characterization of individual nanoemitters and antennas. CL spectroscopy and LDOS imaging of individual NAs is demonstrated as a powerful technique to experimentally determine antennas parameters for the fabrication of coupled plasmonic-semiconductor emitters. Furthermore, we demonstrate two effects of the NA on the QD: an absorption enhancement of a factor 2, and a light emission enhancement due to radiative coupling to the antenna up to a factor 2.5 in a region of high plasmonic losses, extending the control of light emission from semiconducting nanostructures towards the visible spectral region. The effect could be greatly increased for a smaller QD-antenna distance, i.e. using a thinner NW shell. Implementation of the method is a crucial step towards fabricating more complex and versatile coupled structures. It can be applied to all kind of nanoemitters, aiming at controlling their optical properties like their polarization response [10,4] or emission diagram [6,9].

Figure 1 .

 1 Figure 1. (a) Nanowires morphology: an Au droplet serves as a catalyst to grow a CdTe quantum dot inserted in a ZnTe conical nanowire. A lateral regrowth of ZnMgTe creates a shell around this core. (b) typical µPL spectrum of a nanowire QD and (c) corresponding decay rate measurement, integrating a bandwidth of 10 nm around 622 nm. A monoexponential fit (red line) gives a lifetime τ = 1.18±0.01 ns.

Figure 2 .

 2 Figure 2. (a) Schematic of the NA-NW geometry (left: side view, and right: top view), to scale. (b) Cathodoluminescence spectra of the rectangular nanoantennas, with Gaussian fits of the main component (red dashes) and the dipolar mode (blue dashes) discussed in the text. The green line corresponds to (e). The blue line with squares indicates the fitted central wavelength of the dipolar resonance. The blue and brown shaded areas correspond to the integrated bandwidth in (c) (blue) and (d) (brown) respectively. (c) and (d) LDOS imaging of the 111 nm long antenna around 700 nm and 600 nm respectively, with 100 nm spectral integration bandwidth. The blue and brown rectangles correspond to the antenna boundary. (e) Cut profile of the CL intensity along λ QD = 620 nm [green solid line on (b)] showing an increase of the measured LDOS for an antenna length of 97 nm due to the onset of the dipolar mode.

Figure 3 .

 3 Figure 3. (a) Large field SEM image of the sample after antenna fabrication. The dashed lines indicate the position of the fine alignment marks which were exposed during the last alignment step and are hardly visible under the final Au layer. (b) Higher magnification SEM image of the NW after alignment with respect to the marks (c) Filtered CL intensity at λ QD = 620 nm at the same position and magnification. The red cross in (b) indicates the center of the bi-dimensional Gaussian fit. The white lines in (c) are contour lines of the fit. (d) SEM image of the resulting coupled NW-NA system, along with (e) another NA-NW system. The NA-NW gap is 60 nm in (d), while a point contact is achieved in (e). The red arrows indicates the polarization direction of the emitted light, which is ensured to be aligned with the antenna dipolar mode axis.

4 .

 4 Hybrid NW-NA structures 4.1. Fabrication Two examples of the target structure are shown in figures 3 (d)-(e). Fine alignment marks are first fabricated around the chosen NWs using electron-beam lithography, metal evaporation and lift-off [figure 3 (a)]. We then record a SEM image [figure 3 (b)] together with the CL intensity image at λ QD = 620 nm [figure 3 (c)]. Both images are acquired after aligning the microscope beam using the fine alignment marks. Acquisition

Figure 4 .

 4 Figure 4. (a) Integrated µPL intensity for one NWQD as a function of excitation power before (orange square) and after (blue circle) nanoantenna fabrication. The NA is 63 nm long. Each data set is fitted with two components, a constant saturation intensity I s , and a linear function of slope g describing the QD emission at low pumping power. The saturation intensity is determined by the last data point. The slope at the origin is determined between the first data point and the origin. (b) Saturation intensity I s for different NA-NW system divided by the corresponding value of the NW without antenna I s0 as a function of antenna length L. The error bars are given by the detection noise of the spectrometer. (c) Slope at the origin g for different NA-NW system divided by the corresponding value of the NW without antenna g 0 as a function of antenna length L. The error bars are evaluated by comparing the slope at the origin and a linear regression between the first two data points and the origin. The arrow in (b) and (c) corresponds to the NWQD presented in (a). The dotted line in each figure indicates a factor of 1.

Acknowledgments

We acknowledge the help of Institut Néel technical support teams Nanofab (clean room) and optical engineering (CL, Fabrice Donatini). This work was supported by the French National Research Agency (project Magwires, ANR-11-BS10-013 and Labex LANEF du Programme d'Investissements d'Avenir ANR-10-LABX-51-01)