Élément de sécurité de Contrôle d'Accès sur ICS 4.0.4

J'ai mis à jour mon mobile Android 4.0.4 et j'ai remarqué qu'un nouveau fichier nfcee access.xml est apparu dans le dossier système. L'idée de le fichier que j'ai compris est de garder une liste de signatures, et de permettre l'accès à la SE et liées à l'intention uniquement pour les paquets qui sont signés avec un de ces signatures. Jusqu'à présent dans cette liste est bien sûr la signature de du Google Wallet.

Quelqu'un sait comment serait le processus à l'avenir d'accéder à cette liste? Avez-vous besoin de demander directement l'autorisation de Google?

OriginalL'auteur Kamen Goranchev | 2012-05-08

android nfc

17

Si vous la racine de votre téléphone, vous pouvez modifier le fichier. Le fichier contient la liste des signatures et des noms de paquetages qui sont autorisés à accéder à l'Élément Sécurisé (SE). Les signatures est codé en hexadécimal X. 509 certificate. Pour en créer un, il suffit d'inclure la balise <debug /> dans le fichier et il va imprimer à logcat l'codé en hexadécimal signature des applications qui sont privés de SE accéder, pour la simple couper-coller dans ce dossier.

De créer une application qui peut accéder à la SE, vous devez ajouter cette autorisation pour le manifeste:
```
<uses-permission android:name="android.permission.WRITE_SECURE_SETTINGS" />
```
Réellement accès à la SE, vous devez accéder à un caché de l'API par l'importation de com.android.nfc_extras:
```
import com.android.nfc_extras.NfcAdapterExtras;
import com.android.nfc_extras.NfcAdapterExtras.CardEmulationRoute;
import com.android.nfc_extras.NfcExecutionEnvironment;
```
La façon la plus simple pour ce faire est de compiler votre application dans l'Android arborescence du code source, en le plaçant dans packages/apps et de les construire à partir de là. Vous devez ajouter la ligne suivante à la Android.mk makefile pour obtenir l'accès à la SE API:
```
LOCAL_JAVA_LIBRARIES := com.android.nfc_extras
```
Les fonctions dans com.android.nfc_extras permettre l'activation et la désactivation de la SE, l'envoi de commandes et la réception des réponses de (comparable à IsoDep.transceive()).

wow! +1. Je ne connaissais pas le caché de l'api. De toute façon, connaissez-vous des liens à ce sujet? Ou étape par étape la procédure pas à pas pour commencer?
Jetez un oeil à ce post par @NikolayElenkov

OriginalL'auteur NFC guy
6

Ce qui est intéressant en effet. Si l'entrée de votre certificat et le nom du package dans ce fichier est tout ce qui est nécessaire, vous ne devriez pas avoir besoin de parler à Google, il suffit de faire celui qui est la construction de la ROM (vous-même si la ROM custom, ou un transporteur particulier) afin de l'inclure. Le plus gros problème est,
qui avez-vous besoin de parler pour obtenir le CardManager clés. Si c'est le transporteur, vous pouvez également les obtenir à pré-installer votre applet, de sorte que vous n'ayez pas les clés au moment de l'exécution (sauf si vous souhaitez utiliser un canal sécurisé pour votre applet).

Mise à jour: Voici un résumé de SE soutenir dans Android et certains plus d'informations sur la façon d'utiliser le imbriqués les uns. En bref, il fait le travail, mais vous ne pouvez requête choses bien sûr. Il fonctionne JavaCard et GP 2.1.1 compatible, utilise 3DES clés pour le canal sécurisé.

http://nelenkov.blogspot.com/2012/08/accessing-embedded-secure-element-in.html

http://nelenkov.blogspot.com/2012/08/android-secure-element-execution.html

BTW, voici la actuellement autorisés cert sur mon GN 4.0.4. Un paquet n'est pas spécifiée, toutes les applis signées avec celui-ci aura accès à la SE:
```
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            a8:cd:17:c9:3d:a5:d9:90
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=California, L=Mountain View, O=Google Inc., OU=Android, CN=Google NFC
        Validity
            Not Before: Mar 24 01:06:53 2011 GMT
            Not After : Aug  9 01:06:53 2038 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google Inc., OU=Android, CN=Google NFC
```
Je suis d'accord que le problème réel est la Carte de Gestion de Clés, mais si Google propose à l'avenir TSM service cela peut permettre à d'autres parties de la SE. Mon opinion est que si Google n'ouvrez pas un peu plus, les cartes SIM ou de la carte MicroSD deviendra très vite le meilleur SE. Je voulais juste savoir si quelqu'un connais les plans d'avenir de Google dans cette direction.
Eh bien, je ne peux pas parler de plans de Google, mais depuis que Google Wallet n'est pas particulièrement grand, peut-être qu'ils vont ouvrir pour laisser d'autres/similaire/compétition de paiement NFC services de travail avec la SE sur les appareils Nexus.

OriginalL'auteur Nikolay Elenkov
2

Avec cavets: Si vous pouvez obtenir votre application sur le nfcee_access liste, vous pouvez faire les choses suivantes:
- Permettre l'UICC (carte sim) et de permettre à l'élément sécurisé embarqué (si présent)
- Ouvrir un canal de communication à l'élément sécurisé embarqué et l'échange de données
- Recevoir des données de transaction de l'UICC (carte sim) si l'UICC veut vous envoyer des données (vous serez destinataire uniquement).
Vous pouvez faire tout cela si vous la racine de votre téléphone. Pas besoin de pirater le nfcee_access liste pour ce faire, il vous suffit d'intercepter tout le trafic de la puce nfc de faire ça.

Ce que vous ne pouvez pas le faire, même avec un téléphone enracinée:
- Installer des applets sur l'UICC /eSE
- Log/Moniteur/une influence sur le transfert de données entre l'élément sécurisé embarqué/UICC et un lecteur externe, par exemple, de pirater les systèmes de paiement.
Mise en garde: Vous pouvez faire presque tout ce si, et seulement si vous avez les connaissances et l'accès sécurisé-clés pour accéder à l'embedded SE. Toutefois, si vous avez ces informations, vous ne demanderiez pas sur stack overflow. 🙂

Cette connaissance est un secret bien gardé et personne ne vous dira ce secret, sauf si vous êtes une entreprise aussi grande que google, mastercard, visa, american express et la comme.

OriginalL'auteur Nils Pipenbrinck
0

La réponse est simplement NON vous ne pouvez pas faire n'importe quoi avec l'Élément Sécurisé. Seulement SE, du propriétaire ou de l'émetteur peut permettre l'accès à la SE - c'est Google lui-même, ou peut-être le Premier de Données (http://www.firstdata.com/en_us/products/merchants/mobile-commerce/trusted-service-manager-solution.html)mais je pense que cette société n'est responsable que pour le Google Wallet lui-même, pas pour la version SE de la gestion - ce qui pourrait faire de la SK C&C - je n'ai aucune idée...

Prendre elle aussi de cette façon - la condition préalable pour l'utilisation d'élément sécurisé embarqué, c'est que vous êtes en offrant un excellent service et vous êtes partenaires de Google ou d'un autre fabricant de téléphone partenaire (sauf si vous êtes en provenance de Facebook ou similaire entreprise d'économiser votre temps et ne pas essayer). Ce n'est pas facile et 99,99% des services ne peut pas être là.

Concernant l'élément sécurisé maintenant, vous pouvez attendre jusqu'à ce que le SWP cartes SIM deviendra de plus en plus populaire et solution acceptable, car vous pourriez être en mesure d'obtenir un contrat avec MNO au niveau national, plus facile ou de l'espoir dans la NFC-WI et carte SD solution ou aller avec des autocollants ou accessoires externes comme iCarte pour iPhone.

BR
STeN

Est-ce basé sur les réels de la politique/de fait, ou êtes-vous juste de deviner ici?", la condition préalable pour l'utilisation d'élément sécurisé embarqué, c'est que vous êtes en offrant un excellent service et vous êtes à la Google"
Salut, je suppose, d'après mon expérience. Savez-vous tout autre service Google Wallet pour le Sprint? Si vous cochez ce qui se passe dans la NFC industrie, il est "le combat de SOI", parce que si vous controll la SE vous participer sur le revenu. L'espace SE est précieux et seront principalement utilisés pour des solutions de paiement, MNO applications et de gros services comme l'Huître. Il est de confiance des entreprises - à moins que l'ensemble de l'écosystème du changement. Donc, l'idée que vous allez avoir de belles solution pour sécuriser votre serrure de porte et vous souhaitez exécuter le service dans incorporé SE est que je pense que l'Utopie. J'ai peut-être tort, bien sûr...
Il est clair pour moi que, au moment de l'élément sécurisé embarqué n'est pas disponible pour quelqu'un d'autre que Google. Mais j'ai juste dit que ce dernier changement dans le NFCService est l'indication que Google va dans la direction qui va permettre à l'avenir des tiers ont des applications à l'aide de la SE. Bien sûr, après l'approbation de Google. Quelque chose comme de la JANTE est en train de faire en ce moment avec leur élément sécurisé.
Je ne peux pas parler du NFC marché aux etats-unis, mais ici c'est assez développé, et les paiements mobiles NFC ont été disponibles pendant plus de 5 ans. Pas sûr de savoir comment le tout est joué, mais il existe de nombreux services en concurrence, et que vous utilisez habituellement tous sur la même puce. Et chacun a sa propre banque 🙂
Bien - lesquels paiements mobiles et les pays dans lesquels sont largement disponibles (ce qui signifie pas de projets pilotes pour quelques centaines ou milliers de clients)? Et qui d'entre eux sont l'aide d'embedded SE et qui sont à l'aide de passif autocollants, qui sont normales sans contact RFID des cartes de paiement, iCarte ou de la carte SIM??? Et même il y a quelques elle est toujours la coopération de la banque, TSM, l'émetteur de la carte (Visa, MasterCard), le terminal de point de vente du fournisseur et éventuellement MNO. Donc, nous parlons de milliards de dollars - et nous sommes de retour encore une fois - qu'ils ont le pouvoir d'être partenaires de Google ou d'un autre fabricant de téléphone partenaire...

OriginalL'auteur STeN

Vous devez vous connecter pour publier un commentaire.