Créer une application de carte à puce NFC

Cette rubrique décrit comment utiliser l’émulation de carte hôte (HCE) pour communiquer directement avec un lecteur de carte à communication en champ proche (NFC) et permettre à vos clients d’accéder à vos services via leur téléphone (au lieu d’une carte physique) sans passer par un opérateur de réseau mobile (ORM).

Ce dont vous avez besoin pour développer une application HCE

Pour développer une application d’émulation de carte basée sur HCE, vous devez installer Microsoft Visual Studio 2015 (voir la page de téléchargement de Visual Studio) (comprend les outils de développement Windows) et l’émulateur Windows 10 Mobile.

Pour plus d’informations sur l’installation, voir Tester avec l’émulateur Microsoft pour Windows 10 Mobile.

En option, si vous souhaitez tester avec un véritable appareil Windows 10 Mobile au lieu de l’émulateur Windows 10 Mobile inclus, vous aurez également besoin des éléments suivants.

• Un appareil Windows 10 Mobile avec prise en charge NFC HCE.
• Un terminal de lecture prenant en charge les protocoles ISO/IEC 14443-4 et ISO/IEC 7816-4.

Windows 10 Mobile met en œuvre un service HCE qui fournit les fonctionnalités suivantes.

• Les applications peuvent enregistrer les identifiants d’applets (AID) des cartes qu’elles souhaitent émuler.
• Résolution des conflits et acheminement des paires de commandes et de réponses APDU (Application Protocol Data Unit) vers l’une des apps enregistrées en fonction de la sélection de la carte de lecteur externe et des préférences de l’utilisateur.
• Traitement des événements et des notifications aux applications suite aux actions de l’utilisateur.

Windows 10 prend en charge l’émulation des cartes à puce basées sur ISO-DEP (ISO-IEC 14443-4) et communique à l’aide d’APDU tels que définis dans la spécification ISO-IEC 7816-4. Windows 10 prend en charge la technologie ISO/IEC 14443-4 de type A pour les applications HCE. Les technologies de type B, de type F et les technologies non ISO-DEP (p. ex. MIFARE) sont acheminées par défaut vers la carte SIM.

Seuls les appareils Windows 10 Mobile sont activés avec la fonctionnalité d’émulation de carte. L’émulation de cartes SIM et HCE n’est pas disponible sur les autres versions de Windows 10.

L’architecture de la prise en charge de l’émulation de cartes HCE et SIM est illustrée dans le diagramme ci-dessous.

Sélection des applications et acheminement de l’AID

Pour développer une application HCE, vous devez comprendre comment les appareils Windows 10 Mobile acheminent les AID vers une application spécifique, car les utilisateurs peuvent installer plusieurs applications HCE différentes. Chaque application peut enregistrer plusieurs cartes HCE et cartes basées sur la carte SIM.

Lorsque l’utilisateur appuie son appareil Windows 10 Mobile sur un terminal, les données sont automatiquement acheminées vers l’application appropriée installée sur l’appareil. Ce routage est basé sur l’identifiant de l’applet (AID) qui est un identifiant de 5 à 16 octets. Lors d’un appui, le terminal externe transmet une commande SELECT APDU pour spécifier l’AID vers lequel il souhaite que toutes les commandes APDU ultérieures soient acheminées. Les commandes SELECT suivantes modifieront à nouveau l’acheminement. En fonction des AID enregistrés par les applications et des paramètres de l’utilisateur, le trafic APDU est acheminé vers une application spécifique, qui enverra une réponse APDU. Sachez qu’un terminal peut vouloir communiquer avec plusieurs applications différentes au cours d’un même appui. Vous devez donc vous assurer que la tâche d’arrière-plan de votre application se termine le plus rapidement possible lorsqu’elle est désactivée, afin de laisser la place à la tâche d’arrière-plan d’une autre application pour répondre à l’APDU. Nous aborderons les tâches d’arrière-plan plus loin dans cette rubrique.

Les applications HCE doivent s’enregistrer avec des AID particuliers qu’elles peuvent gérer afin de recevoir des APDU pour un AID. Les applications déclarent les AID en utilisant des groupes d’AID. Un groupe d’AID est conceptuellement équivalent à une carte physique individuelle. Par exemple, une carte de crédit est déclarée avec un groupe d’AID et une deuxième carte de crédit d’une banque différente est déclarée avec un deuxième groupe d’AID différent, même si elles ont toutes les deux le même AID.

Résolution des conflits pour les groupes d’AID de paiement

Lorsqu’une application enregistre des cartes physiques (groupes AID), elle peut déclarer la catégorie du groupe AID comme "Paiement" ou "Autre". Bien qu’il puisse y avoir plusieurs groupes AID de paiement enregistrés à un moment donné, un seul de ces groupes AID de paiement peut être activé pour Appuyer et payer à la fois, ce qui est sélectionné par l’utilisateur. Ce comportement existe parce que l’utilisateur est censé choisir consciemment une seule carte de paiement, de crédit ou de débit à utiliser afin de ne pas payer avec une autre carte involontaire lorsqu’il appuie son appareil sur un terminal.

Cependant, plusieurs groupes AID enregistrés comme "Autres" peuvent être activés en même temps sans interaction de la part de l’utilisateur. Ce comportement existe parce que d’autres types de cartes, comme les cartes de fidélité, les coupons ou les cartes de transport, sont censées fonctionner sans effort ni invitation lorsque l’utilisateur appuie sur son téléphone.

Tous les groupes AID enregistrés comme "Paiement" apparaissent dans la liste des cartes de la page Paramètres NFC, où l’utilisateur peut sélectionner sa carte de paiement par défaut. Lorsqu’une carte de paiement par défaut est sélectionnée, l’application qui a enregistré ce groupe d’AID de paiement devient l’application de paiement par défaut. Les applications de paiement par défaut peuvent activer ou désactiver n’importe lequel de leurs groupes AID sans intervention de l’utilisateur. Si l’utilisateur refuse l’application de paiement par défaut, l’application de paiement par défaut actuelle (s’il y en a une) reste l’application par défaut. La capture d’écran suivante montre la page des paramètres NFC.

Dans l’exemple de la capture d’écran ci-dessus, si l’utilisateur change sa carte de paiement par défaut pour une autre carte qui n’est pas enregistrée par l’"Application HCE 1", le système crée une demande de confirmation pour obtenir le consentement de l’utilisateur. En revanche, si l’utilisateur remplace sa carte de paiement par défaut par une autre carte enregistrée par l’"application HCE 1", le système ne crée pas de demande de confirmation pour l’utilisateur car l’"application HCE 1" est déjà l’application de paiement par défaut.

Résolution des conflits pour les groupes AID de non-paiement

Les cartes de non-paiement classées dans la catégorie "Autre" n’apparaissent pas dans la page des paramètres NFC.

Votre application peut créer, enregistrer et activer des groupes AID de non-paiement de la même manière que les groupes AID de paiement. La principale différence est que pour les groupes AID de non-paiement, la catégorie d’émulation est réglée sur "Autre" au lieu de "Paiement". Après avoir enregistré le groupe AID dans le système, vous devez l’autoriser à recevoir du trafic NFC. Lorsque vous essayez d’activer un groupe d’AID de non-paiement pour recevoir du trafic, l’utilisateur n’est pas invité à confirmer, à moins qu’il n’y ait un conflit avec l’un des AID déjà enregistrés dans le système par une application différente. En cas de conflit, l’utilisateur est invité à indiquer la carte et l’application associée qui seront désactivées si l’utilisateur choisit d’activer le groupe d’AID nouvellement enregistré.

Coexistence avec les applications NFC basées sur la carte SIM

Dans Windows 10 Mobile, le système établit la table de routage du contrôleur NFC qui est utilisée pour prendre des décisions de routage au niveau du contrôleur. La table contient des informations de routage pour les éléments suivants.

• Itinéraires AID individuels.
• Itinéraire basé sur le protocole (ISO-DEP).
• Routage basé sur la technologie (NFC-A/B/F).

Lorsqu’un lecteur externe envoie une commande "SELECT AID", le contrôleur NFC vérifie d’abord les itinéraires AID dans la table de routage. S’il n’y a pas de correspondance, il utilisera la route basée sur le protocole comme route par défaut pour le trafic ISO-DEP (14443-4-A). Pour tout autre trafic non ISO-DEP, il utilisera le routage basé sur la technologie.

Windows 10 Mobile propose une option de menu "Carte SIM" dans la page Paramètres NFC pour continuer à utiliser les applications héritées de Windows Phone 8.1 basées sur la carte SIM, qui n’enregistrent pas leurs AID avec le système. Si l’utilisateur sélectionne "carte SIM" comme carte de paiement par défaut, la route ISO-DEP est définie sur UICC, pour toutes les autres sélections dans le menu déroulant, la route ISO-DEP est vers l’hôte.

La route ISO-DEP est définie sur "Carte SIM" pour les appareils qui ont une carte SIM activée par SE lorsque l’appareil est démarré pour la première fois avec Windows 10 Mobile. Lorsque l’utilisateur installe une application compatible HCE et que cette application active tout enregistrement de groupe AID HCE, la route ISO-DEP sera dirigée vers l’hôte. Les nouvelles applications basées sur la carte SIM doivent enregistrer les AID dans la carte SIM pour que les routes AID spécifiques soient renseignées dans la table de routage du contrôleur.

Création d’une application HCE

Votre application HCE se compose de deux parties.

• L’application principale de premier plan pour l’interaction avec l’utilisateur.
• Une tâche d’arrière-plan déclenchée par le système pour traiter les APDU pour un AID donné.

En raison des exigences extrêmement strictes en matière de performances pour le chargement de votre tâche d’arrière-plan en réponse à un appui NFC, nous vous recommandons de mettre en œuvre l’ensemble de votre tâche d’arrière-plan en code natif C++/CX (y compris toutes les dépendances, références ou bibliothèques dont vous dépendez) plutôt qu’en code C# ou géré. Bien que le code C# et le code géré fonctionnent normalement bien, il y a des frais généraux, comme le chargement du CLR .NET, qui peuvent être évités en l’écrivant en C++/CX.

Créez et enregistrez votre tâche d’arrière-plan

Vous devez créer une tâche d’arrière-plan dans votre application HCE pour traiter et répondre aux APDU qui lui sont envoyés par le système. Lors du premier lancement de votre application, le premier plan enregistre une tâche d’arrière-plan HCE qui implémente l’interface IBackgroundTaskRegistration, comme le montre le code suivant.

var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorHostApplicationActivated));
bgTask = taskBuilder.Register();

Notez que le déclencheur de la tâche est défini sur SmartCardTriggerType. EmulatorHostApplicationActivated. Cela signifie qu’à chaque fois qu’un APDU de commande SELECT AID est reçu par le système d’exploitation se rapportant à votre application, votre tâche d’arrière-plan est lancée.

Recevoir des APDU et y répondre

Lorsqu’un APDU est destiné à votre application, le système lance votre tâche d’arrière-plan. Votre tâche d’arrière-plan reçoit l’APDU passé par la propriété CommandApdu de l’objet SmartCardEmulatorApduReceivedEventArgs et répond à l’APDU en utilisant la méthode TryRespondAsync du même objet. Pour des raisons de performances, vous pouvez envisager de conserver votre tâche d’arrière-plan pour des opérations légères. Par exemple, répondez immédiatement aux APDU et quittez votre tâche d’arrière-plan lorsque le traitement est terminé. En raison de la nature des transactions NFC, les utilisateurs ont tendance à ne maintenir leur appareil contre le lecteur que pendant un très court laps de temps. Votre tâche d’arrière-plan continuera à recevoir du trafic du lecteur jusqu’à ce que votre connexion soit désactivée, auquel cas vous recevrez un objet SmartCardEmulatorConnectionDeactivatedEventArgs. Votre connexion peut être désactivée pour les raisons suivantes, indiquées dans la propriété SmartCardEmulatorConnectionDeactivatedEventArgs.Reason.

• Si la connexion est désactivée avec la valeur ConnectionLost, cela signifie que l’utilisateur a éloigné son appareil du lecteur. Si votre application nécessite que l’utilisateur appuie plus longtemps sur le terminal, vous pouvez envisager de l’y inviter par un retour d’information. Vous devriez terminer votre tâche d’arrière-plan rapidement (en complétant votre report) pour vous assurer que si l’utilisateur appuie à nouveau, il ne sera pas retardé en attendant que la tâche d’arrière-plan précédente se termine.
• Si la connexion est désactivée avec ConnectionRedirected, cela signifie que le terminal a envoyé une nouvelle commande SELECT AID APDU dirigée vers un AID différent. Dans ce cas, votre application doit quitter la tâche d’arrière-plan immédiatement (en terminant votre report) pour permettre à une autre tâche d’arrière-plan de s’exécuter.

La tâche d’arrière-plan doit également s’enregistrer pour l’événement Canceled sur l’interface IBackgroundTaskInstance et, de la même manière, quitter rapidement la tâche d’arrière-plan (en terminant votre report) car cet événement est déclenché par le système lorsqu’il en a terminé avec votre tâche d’arrière-plan. Vous trouverez ci-dessous un code qui illustre une tâche d’arrière-plan d’une application HCE.

void BgTask::Run(
    IBackgroundTaskInstance^ taskInstance)
{
    m_triggerDetails = static_cast<SmartCardTriggerDetails^>(taskInstance->TriggerDetails);
    if (m_triggerDetails == nullptr)
    {
        // May be not a smart card event that triggered us
        return;
    }

    m_emulator = m_triggerDetails->Emulator;
    m_taskInstance = taskInstance;

    switch (m_triggerDetails->TriggerType)
    {
    case SmartCardTriggerType::EmulatorHostApplicationActivated:
        HandleHceActivation();
        break;

    case SmartCardTriggerType::EmulatorAppletIdGroupRegistrationChanged:
        HandleRegistrationChange();
        break;

    default:
        break;
    }
}

void BgTask::HandleHceActivation()
{
 try
 {
        auto lock = m_srwLock.LockShared();
        // Take a deferral to keep this background task alive even after this "Run" method returns
        // You must complete this deferral immediately after you have done processing the current transaction
        m_deferral = m_taskInstance->GetDeferral();

        DebugLog(L"*** HCE Activation Background Task Started ***");

        // Set up a handler for if the background task is cancelled, we must immediately complete our deferral
        m_taskInstance->Canceled += ref new Windows::ApplicationModel::Background::BackgroundTaskCanceledEventHandler(
            [this](
            IBackgroundTaskInstance^ sender,
            BackgroundTaskCancellationReason reason)
        {
            DebugLog(L"Cancelled");
            DebugLog(reason.ToString()->Data());
            EndTask();
        });

        if (Windows::Phone::System::SystemProtection::ScreenLocked)
        {
            auto denyIfLocked = Windows::Storage::ApplicationData::Current->RoamingSettings->Values->Lookup("DenyIfPhoneLocked");
            if (denyIfLocked != nullptr && (bool)denyIfLocked == true)
            {
                // The phone is locked, and our current user setting is to deny transactions while locked so let the user know
                // Denied
                DoLaunch(Denied, L"Phone was locked at the time of tap");

                // We still need to respond to APDUs in a timely manner, even though we will just return failure
                m_fDenyTransactions = true;
            }
        }
        else
        {
            m_fDenyTransactions = false;
        }

        m_emulator->ApduReceived += ref new TypedEventHandler<SmartCardEmulator^, SmartCardEmulatorApduReceivedEventArgs^>(
            this, &BgTask::ApduReceived);

        m_emulator->ConnectionDeactivated += ref new TypedEventHandler<SmartCardEmulator^, SmartCardEmulatorConnectionDeactivatedEventArgs^>(
                [this](
                SmartCardEmulator^ emulator,
                SmartCardEmulatorConnectionDeactivatedEventArgs^ eventArgs)
            {
                DebugLog(L"Connection deactivated");
                EndTask();
            });

  m_emulator->Start();
        DebugLog(L"Emulator started");
 }
 catch (Exception^ e)
 {
        DebugLog(("Exception in Run: " + e->ToString())->Data());
        EndTask();
 }
}

Créez et enregistrez les groupes AID

Lors du premier lancement de votre application, lorsque la carte est approvisionnée, vous créerez et enregistrerez des groupes AID avec le système. Le système détermine l’application à laquelle un lecteur externe souhaite s’adresser et achemine les APDU en conséquence, sur la base des AID enregistrés et des paramètres de l’utilisateur.

La plupart des cartes de paiement s’enregistrent pour le même AID, Proximity Payment System Environment (PPSE), ainsi que pour d’autres AID spécifiques aux cartes des réseaux de paiement. Chaque groupe d’AID représente une carte et lorsque l’utilisateur active la carte, tous les AID du groupe sont activés. De même, lorsque l’utilisateur désactive la carte, tous les AID du groupe sont désactivés.

Pour enregistrer un groupe d’AID, vous devez créer un objet SmartCardAppletIdGroup et définir ses propriétés pour indiquer qu’il s’agit d’une carte de paiement HCE. Votre nom d’affichage doit être descriptif pour l’utilisateur car il apparaîtra dans le menu des paramètres NFC ainsi que dans les invites de l’utilisateur. Pour les cartes de paiement HCE, la propriété SmartCardEmulationCategory doit être réglée sur Payment et la propriété SmartCardEmulationType doit être réglée sur Host.

public static byte[] AID_PPSE =
        {
            // File name "2PAY.SYS.DDF01" (14 bytes)
            (byte)'2', (byte)'P', (byte)'A', (byte)'Y',
            (byte)'.', (byte)'S', (byte)'Y', (byte)'S',
            (byte)'.', (byte)'D', (byte)'D', (byte)'F', (byte)'0', (byte)'1'
        };

var appletIdGroup = new SmartCardAppletIdGroup(
                        "Example DisplayName",
                                new List<IBuffer> {AID_PPSE.AsBuffer()},
                                SmartCardEmulationCategory.Payment,
                                SmartCardEmulationType.Host);

Pour les cartes HCE sans paiement, la propriété SmartCardEmulationCategory doit être définie sur Other et la propriété SmartCardEmulationType doit être définie sur Host.

public static byte[] AID_OTHER =
        {
            (byte)'1', (byte)'2', (byte)'3', (byte)'4',
            (byte)'5', (byte)'6', (byte)'7', (byte)'8',
            (byte)'O', (byte)'T', (byte)'H', (byte)'E', (byte)'R'
        };

var appletIdGroup = new SmartCardAppletIdGroup(
                        "Example DisplayName",
                                new List<IBuffer> {AID_OTHER.AsBuffer()},
                                SmartCardEmulationCategory.Other,
                                SmartCardEmulationType.Host);

Vous pouvez inclure jusqu’à 9 AID (de 5 à 16 octets chacun) par groupe d’AID.

Utilisez la méthode RegisterAppletIdGroupAsync pour enregistrer votre groupe d’AID auprès du système, qui renverra un objet SmartCardAppletIdGroupRegistration. Par défaut, la propriété ActivationPolicy de l’objet d’enregistrement est définie sur Disabled. Cela signifie que même si vos AID sont enregistrés dans le système, ils ne sont pas encore activés et ne recevront pas de trafic.

reg = await SmartCardEmulator.RegisterAppletIdGroupAsync(appletIdGroup);

Vous pouvez activer vos cartes enregistrées (groupes AID) en utilisant la méthode RequestActivationPolicyChangeAsync de la classe SmartCardAppletIdGroupRegistration, comme indiqué ci-dessous. Étant donné qu’une seule carte de paiement peut être activée à la fois sur le système, le fait de définir la politique d’activation d’un groupe AID de paiement sur Activé revient à définir la carte de paiement par défaut. L’utilisateur sera invité à autoriser cette carte comme carte de paiement par défaut, qu’il y ait ou non une carte de paiement par défaut déjà sélectionnée. Cette instruction n’est pas valable si votre application est déjà l’application de paiement par défaut et qu’elle ne fait que passer d’un groupe AID à l’autre. Vous pouvez enregistrer jusqu’à 10 groupes AID par application.

reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.Enabled);

Vous pouvez interroger les groupes AID enregistrés de votre application avec le système d’exploitation et vérifier leur stratégie d’activation à l’aide de la méthode GetAppletIdGroupRegistrationsAsync.

Les utilisateurs seront invités à modifier la stratégie d’activation d’une carte de paiement de Désactivée à Activée, uniquement si votre application n’est pas déjà l’application de paiement par défaut. Les utilisateurs ne seront invités à changer la stratégie d’activation d’une carte de non-paiement de Désactivée à Activée que s’il y a un conflit d’AID.

var registrations = await SmartCardEmulator.GetAppletIdGroupRegistrationsAsync();
    foreach (var registration in registrations)
    {
registration.RequestActivationPolicyChangeAsync (AppletIdGroupActivationPolicy.Enabled);
    }

Notification d’événement en cas de changement de stratégie d’activation

Dans votre tâche d’arrière-plan, vous pouvez vous inscrire pour recevoir des événements lorsque la stratégie d’activation de l’un de vos enregistrements de groupe AID est modifiée en dehors de votre application. Par exemple, l’utilisateur peut changer d’application de paiement par défaut via le menu des paramètres NFC et passer de l’une de vos cartes à une autre carte hébergée par une autre application. Si votre application doit être informée de ce changement pour une configuration interne telle que la mise à jour des tuiles en direct, vous pouvez recevoir des notifications d’événements pour ce changement et prendre des mesures dans votre application en conséquence.

var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorAppletIdGroupRegistrationChanged));
bgTask = taskBuilder.Register();

Comportement de remplacement du premier plan

Vous pouvez changer la ActivationPolicy de n’importe lequel de vos enregistrements de groupe AID en ForegroundOverride lorsque votre application est au premier plan, sans que l’utilisateur n’y soit invité. Lorsque l’utilisateur appuie son appareil sur un terminal alors que votre application est au premier plan, le trafic est acheminé vers votre application même si aucune de vos cartes de paiement n’a été choisie par l’utilisateur comme carte de paiement par défaut. Lorsque vous modifiez la stratégie d’activation d’une carte en ForegroundOverride, ce changement n’est que temporaire jusqu’à ce que votre application quitte le premier plan et il ne modifiera pas la carte de paiement par défaut actuelle définie par l’utilisateur. Vous pouvez modifier la politique d’activation de vos cartes de paiement ou de non-paiement à partir de votre application de premier plan en procédant comme suit. Notez que la méthode RequestActivationPolicyChangeAsync ne peut être appelée qu’à partir d’une application de premier plan et ne peut pas être appelée à partir d’une tâche d’arrière-plan.

reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.ForegroundOverride);

Vous pouvez également enregistrer un groupe d’AID composé d’un seul AID de longueur 0, ce qui amènera le système à acheminer tous les APDU, quel que soit l’AID, y compris les APDU de commande envoyés avant la réception d’une commande SELECT AID. Cependant, un tel groupe d’AID ne fonctionne que lorsque votre application est au premier plan, car il ne peut être défini que sur ForegroundOverride et ne peut pas être activé de manière permanente. De plus, ce mécanisme fonctionne à la fois pour les valeurs Host et UICC de l’énumération SmartCardEmulationType afin d’acheminer tout le trafic vers votre tâche d’arrière-plan HCE ou vers la carte SIM.

public static byte[] AID_Foreground =
        {};

var appletIdGroup = new SmartCardAppletIdGroup(
                        "Example DisplayName",
                                new List<IBuffer> {AID_Foreground.AsBuffer()},
                                SmartCardEmulationCategory.Other,
                                SmartCardEmulationType.Host);
reg = await SmartCardEmulator.RegisterAppletIdGroupAsync(appletIdGroup);
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.ForegroundOverride);

Vérifier la prise en charge de la NFC et de la HCE

Votre application doit vérifier si un appareil dispose de matériel NFC, prend en charge la fonctionnalité d’émulation de carte et prend en charge l’émulation de carte hôte avant d’offrir ces fonctionnalités à l’utilisateur.

La fonctionnalité d’émulation de carte à puce NFC n’est activée que sur Windows 10 Mobile, donc essayer d’utiliser les API d’émulation de carte à puce dans toute autre version de Windows 10, provoquera des erreurs. Vous pouvez vérifier la prise en charge de l’API de carte à puce dans l’extrait de code suivant.

Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Devices.SmartCards.SmartCardEmulator");

Vous pouvez également vérifier si l’appareil dispose d’un matériel NFC capable d’une certaine forme d’émulation de carte en vérifiant si la méthode SmartCardEmulator.GetDefaultAsync renvoie null. Si c’est le cas, l’appareil ne prend pas en charge l’émulation de carte NFC.

var smartcardemulator = await SmartCardEmulator.GetDefaultAsync();<

La prise en charge du routage UICC basé sur HCE et AID n’est disponible que sur les appareils lancés récemment, tels que les Lumia 730, 830, 640 et 640 XL. Tous les nouveaux appareils compatibles NFC fonctionnant sous Windows 10 Mobile et les versions ultérieures devraient prendre en charge HCE. Votre application peut vérifier la prise en charge de HCE de la manière suivante.

Smartcardemulator.IsHostCardEmulationSupported();

Comportement de l’écran de verrouillage et de l’écran éteint

Windows 10 Mobile dispose de paramètres d’émulation de carte au niveau de l’appareil, qui peuvent être définis par l’opérateur mobile ou le fabricant de l’appareil. Par défaut, la bascule "appuyer pour payer" est désactivée et la "stratégie d’activation au niveau de l’appareil" est définie sur "Toujours", sauf si le MO ou l’OEM écrase ces valeurs.

Votre application peut interroger la valeur de EnablementPolicy au niveau de l’appareil et prendre des mesures dans chaque cas, en fonction du comportement souhaité de votre application dans chaque état.

SmartCardEmulator emulator = await SmartCardEmulator.GetDefaultAsync();

switch (emulator.EnablementPolicy)
{
case Never:
// you can take the user to the NFC settings to turn "tap and pay" on
await Windows.System.Launcher.LaunchUriAsync(new Uri("ms-settings-nfctransactions:"));
break;

 case Always:
return "Card emulation always on";

 case ScreenOn:
 return "Card emulation on only when screen is on";

 case ScreenUnlocked:
 return "Card emulation on only when screen unlocked";
}

La tâche d’arrière-plan de votre application sera lancée même si le téléphone est verrouillé et/ou si l’écran est éteint uniquement si le lecteur externe sélectionne un AID qui se rapporte à votre application. Vous pouvez répondre aux commandes du lecteur dans votre tâche d’arrière-plan, mais si vous avez besoin d’une entrée de la part de l’utilisateur ou si vous voulez afficher un message à l’utilisateur, vous pouvez lancer votre application de premier plan avec quelques arguments. Votre tâche d’arrière-plan peut lancer votre application de premier plan de la manière suivante.

• Sous l’écran de verrouillage de l’appareil (l’utilisateur ne verra votre application de premier plan qu’après avoir déverrouillé l’appareil).
• Au-dessus de l’écran de verrouillage de l’appareil (après que l’utilisateur a fermé votre application, l’appareil est toujours verrouillé).

        if (Windows::Phone::System::SystemProtection::ScreenLocked)
        {
            // Launch above the lock with some arguments
            var result = await eventDetails.TryLaunchSelfAsync("app-specific arguments", SmartCardLaunchBehavior.AboveLock);
        }

Enregistrement de l’AID et autres mises à jour pour les applications basées sur la carte SIM

Les applications d’émulation de carte qui utilisent la carte SIM comme élément sécurisé peuvent s’enregistrer auprès du service Windows pour déclarer les AID pris en charge sur la carte SIM. Cet enregistrement est très similaire à l’enregistrement d’une application basée sur la technologie HCE. La seule différence réside dans le type de SmartCardEmulationType, qui doit être défini sur Uicc pour les applications basées sur la carte SIM. Suite à l’enregistrement de la carte de paiement, le nom d’affichage de la carte sera également renseigné dans le menu de paramétrage NFC.

var appletIdGroup = new SmartCardAppletIdGroup(
                        "Example DisplayName",
                                new List<IBuffer> {AID_PPSE.AsBuffer()},
                                SmartCardEmulationCategory.Payment,
                                SmartCardEmulationType.Uicc);