Créer des signatures numériques avec Swift

L'objectif principal d'une signature numérique est de vérifier l'intégrité de certaines informations. Par exemple, supposons qu'un fichier ait été transféré sur le réseau et que vous souhaitiez vérifier que l'intégralité du fichier a été transférée correctement. Dans ce cas, vous utiliseriez une somme de contrôle.

"Une somme de contrôle est une donnée de petite taille dérivée d'un bloc de données numériques destinée à détecter les erreurs éventuellement introduites lors de sa transmission ou de son stockage" - Wikipedia

Comment obtenons-nous cette somme de contrôle? La meilleure option est d'utiliser un hachage. Une fonction de hachage prendra une quantité variable de données et générera une signature de longueur fixe. Par exemple, nous pourrions publier un fichier avec son hachage en ligne. Lorsque quelqu'un télécharge le fichier, il peut alors exécuter la même fonction de hachage sur sa version du fichier et comparer le résultat. Si les hachages sont identiques, le fichier copié ou téléchargé est identique à l'original..

Un hachage est également une fonction à sens unique. Compte tenu du résultat obtenu, il n’existe aucun moyen réalisable sur le plan informatique d’inverser ce hachage pour révéler le contenu de l’entrée initiale. SHA, Secure Hash Algorithm, est un standard bien connu qui fait référence à un groupe de fonctions de hachage qui possèdent cette propriété et certaines autres, ce qui les rend utiles pour les signatures numériques..

À propos de SHA

SHA a subi de nombreuses itérations depuis sa première publication. Les première et deuxième itérations, SHA-0 et SHA-1, sont maintenant connues pour avoir des faiblesses majeures. Ils ne sont plus approuvés pour les implémentations de sécurité: ils ne doivent généralement pas être utilisés pour des applications reposant sur la sécurité. Cependant, la famille SHA-2 inclut des versions nommées SHA-256 et SHA-512, considérées comme sécurisées. "256" et "512" se réfèrent simplement au nombre résultant de bits produits. Pour ce tutoriel, nous allons utiliser SHA-512.

Remarque: Un autre algorithme de hachage populaire plus ancien était MD5. Il a également été trouvé à avoir des défauts importants.

L'utilisation de SHA est idéale pour vérifier si les données ont été accidentellement corrompues, mais cela n'empêche pas un utilisateur malveillant de falsifier les données. Étant donné qu’une sortie de hachage a une taille fixe, il suffit à l’attaquant de déterminer quel algorithme a été utilisé en fonction de la taille de la sortie, de modifier les données et de recalculer l’empreinte numérique. Nous avons besoin d’informations secrètes ajoutées au mélange lors du hachage des données afin que l’attaquant ne puisse pas recalculer le hachage sans connaître le secret. Ceci s'appelle un code d'authentification de message de hachage (HMAC).

HMAC

HMAC peut authentifier un élément d'information ou un message pour s'assurer qu'il provient de l'expéditeur correct et que les informations n'ont pas été modifiées. Un scénario courant survient lorsque vous parlez à un serveur avec une API back-end pour votre application. Il peut être important de vous authentifier pour vous assurer que seule votre application est autorisée à communiquer avec l'API. L'API aurait contrôle d'accès à une ressource spécifique, telle qu'un / register_user point final. Le client aurait besoin de signe sa demande au / register_user point final afin de l'utiliser avec succès.

Lors de la signature d'une demande, il est courant de prendre certaines parties de la demande, telles que les paramètres POST et l'URL, et de les associer pour former une chaîne. Prendre des éléments convenus et les mettre dans un ordre particulier s’appelle canonisation. Dans HMAC, la chaîne jointe est hachée avec la clé secrète pour produire le Signature. Au lieu d'appeler cela un hachage, nous utilisons le terme signature de la même manière que la signature d'une personne est utilisée dans la vie réelle pour vérifier l'identité ou l'intégrité. La signature est rajoutée à la demande du client sous la forme d'un en-tête de demande (généralement appelé également «Signature»). Une signature est parfois appelée un résumé de message, mais les deux termes peuvent être utilisés indifféremment..

Sur le côté API, le serveur répète le processus de jonction des chaînes et de création d'une signature. Si les signatures correspondent, cela prouve que l'application doit posséder le secret. Cela prouve l'identité de l'application. Etant donné que des paramètres spécifiques de la demande faisaient également partie de la chaîne à signer, cela garantit également l'intégrité de la demande. Il empêche par exemple un attaquant de mener une attaque par interférence et de modifier les paramètres de la requête à sa guise..

class func hmacExample () // Un exemple d'URL… let urlString = "https://example.com" let postString = "id = 123" let url = URL.init (chaîne: urlString) var request = URLRequest (url: url!) request.httpMethod = "POST" request.httpBody = postString.data (using: .utf8) let session = URLSession.shared // Créez une signature, laissez stringToSign = request.httpMethod! + "&" + urlString + "&" + postString print ("La chaîne à signer est:", stringToSign) si let dataToSign = stringToSign.data (using: .utf8) let signerSecret = "4kDfjgQhcw4dG6JVRFbtalAmour .data (using: .utf8) let digestLength = Int (CC_SHA512_DIGEST_LENGTH) let digestBytes = UnsafeMutablePointer.allouer (capacité: digestLength) CCHmac (CCHmacAlgorithm (kCCHmacAlgSHA512), [UInt8] (signatureSecretData), signatureSecretData.count, [UInt8: (dataToSign), dataToSign.count, digestBytes) // base de données (nombre de pages) count: digestLength) let signature = hmacData.base64EncodedString () print ("La signature HMAC en base64 est" + signature) // ou la sortie HEX let let hexString = NSMutableString () pour i en 0…  Dans ce code, le CCHmac function prend un paramètre pour le type de fonction de hachage à utiliser, ainsi que deux chaînes d'octets et leur longueur, le message et une clé secrète. Pour une sécurité optimale, utilisez au moins une clé de 256 bits (32 octets) générée à partir d'un générateur de nombres aléatoires cryptographiquement sécurisé. Pour vérifier que tout fonctionne correctement de l'autre côté, exécutez l'exemple, puis entrez la clé secrète et le message sur ce serveur distant et vérifiez que le résultat est identique..
 Vous pouvez également ajouter un en-tête d'horodatage à la demande et une chaîne de signature pour rendre la demande plus unique. Cela peut aider l’API à éliminer les attaques par rejeu. Par exemple, l'API peut supprimer la demande si l'horodatage est obsolète pendant 10 minutes..
 Bien qu'il soit bon de continuer à utiliser des versions SHA sécurisées, il s'avère que la plupart des vulnérabilités des versions SHA non sécurisées ne s'appliquent pas à HMAC. Pour cette raison, SHA1 peut être utilisé dans le code de production. Toutefois, du point de vue des relations publiques, il peut sembler inacceptable que vous deviez expliquer pourquoi, de manière cryptographique, il est acceptable d’utiliser SHA1 dans ce contexte. Beaucoup des faiblesses de SHA1 sont dues à ce qu'on appelle attaques de collision. Les auditeurs de code ou les chercheurs en sécurité peuvent s’attendre à ce que votre code soit résistant aux collisions, quel que soit le contexte. En outre, si vous écrivez du code modulaire dans lequel vous pourrez remplacer la fonction de signature par une autre, vous risquez peut-être de ne pas mettre à jour les fonctions de hachage non sécurisées. Par conséquent, nous allons continuer à utiliser SHA-512 comme algorithme de choix.
 Les opérations du processeur HMAC sont rapides, mais l’un des inconvénients est le problème de l’échange de clés. Comment pouvons-nous nous faire savoir ce qu'est la clé secrète sans qu'elle soit interceptée? Par exemple, votre API devra peut-être ajouter ou supprimer dynamiquement plusieurs applications ou plates-formes d'une liste blanche. Dans ce scénario, les applications doivent s'inscrire et le secret doit être transmis à l'application une fois l'inscription réussie. Vous pouvez envoyer la clé via HTTPS et utiliser le repérage SSL, mais même dans ce cas, on craint toujours que la clé soit volée pendant l'échange. La solution au problème de l'échange de clés consiste à générer une clé qui n'a pas besoin de quitter le périphérique en premier lieu. Ceci peut être accompli en utilisant la cryptographie à clé publique, et une norme très populaire et acceptée est RSA.
RSA
 RSA signifie Rivest-Shamir-Adleman (les auteurs du cryptosystème). Cela implique de tirer parti de la difficulté de factoriser le produit de deux nombres premiers très grands. RSA peut être utilisé pour le cryptage ou l'authentification, bien que pour cet exemple, nous allons l'utiliser uniquement pour l'authentification. RSA génère deux clés, une publique et une privée, que nous pouvons accomplir en utilisant le SecKeyGeneratePair une fonction. Lorsqu'elle est utilisée pour l'authentification, la clé privée est utilisée pour créer la signature, tandis que la clé publique vérifie la signature. Avec une clé publique, il est impossible de calculer la clé privée par calcul..
 L'exemple suivant montre ce qu'Apple et toutes les sociétés de consoles de jeu populaires utilisent pour distribuer leurs logiciels. Supposons que votre entreprise crée et diffuse régulièrement un fichier que les utilisateurs glissent dans la partie de partage de fichiers de votre application dans iTunes. Vous voulez vous assurer que les fichiers que vous envoyez ne sont jamais falsifiés avant d'être analysés dans l'application. Votre entreprise conservera et gardera la clé privée qu’elle utilise pour signer les fichiers. Dans le paquet de l'application est une copie de la clé publique utilisée pour vérifier le fichier. Étant donné que la clé privée n'est jamais transmise ni incluse dans l'application, il est impossible pour un utilisateur malveillant de signer sa propre version des fichiers (à part pénétrer dans l'entreprise et voler la clé privée)..
 Nous utiliserons SecKeyRawSign signer le fichier. Il serait lent de signer l'intégralité du contenu du fichier à l'aide de RSA. Le hachage du fichier est donc signé. De plus, les données transmises à RSA doivent également être hachées avant la signature en raison de certaines faiblesses en matière de sécurité..
@available (iOS 10.0, *) class FileSigner private var publicKey: SecKey? private var privateKey: SecKey? func generateKeys () -> Chaîne? var publicKeyString: String? // génère une nouvelle paire de paramètres let: [String: AnyObject] = [kSecAttrKeyType en tant que String: kSecAttrKeyTypeRSA, kSecAttrKeySizeInBits en tant que String: 4096 en tant que AnyObject,] let status = SecKeyGeneratePair (paramètres tels que CFDictionary, & publicKey), your key here --- // // Convertissez l'objet SecKey en une représentation que nous pouvons envoyer sur le réseau si status == noErr && publicKey! = nil si let cfData = SecKeyCopyExternalRepresentation (publicKey !, nil) let data = cfData en tant que Data publicKeyString = data.base64EncodedString () return publicKeyString func signFile (_ path: String) -> String? var signature: String? if let fileData = FileManager.default.contents (atPath: chemin) if (privateKey! = nil) // commence par hacher le message, laissez digestLength = Int (CC_SHA512_DIGEST_LENGTH) laisse hashBytes = UnsafeMutablePointer.allocate (capacity: digestLength) CC_SHA512 ([UInt8] (fileData), CC_LONG (fileData.count), hashBytes) // signe let blockSize = SecKeyGetBlockSize (privateKey!) // dans le cas de RSA, modulus est identique à un bloc size var signatureBytes = [UInt8] (en répétant: 0, count: blockSize) var signatureDataLength = blockSize let status = SecKeyRawSign (privateKey !, .PKCS1SHA512, hashBytes, digestLength, & signatureBytes, & signatureDataLength) si status == noErr let data = data ( octets: signatureBytes, count: signatureDataLength) signature = data.base64EncodedString () renvoyer la signature
 Dans ce code, nous avons utilisé le CC_SHA512 fonction pour spécifier SHA-512 à nouveau. (RSA, contrairement à HMAC, devient instable si la fonction de hachage sous-jacente n’est pas sécurisée.) Nous utilisons également 4096 comme taille de clé, définie par le paramètre kSecAttrKeySizeInBits paramètre. 2048 est la taille minimale recommandée. Cela permet d'éviter qu'un réseau informatique puissant ne déchiffre la clé RSA (par craquage, je veux dire la factorisation de la clé RSA - également appelée factorisation d'un module public). Le groupe RSA a estimé que les clés 2048 bits pourraient devenir fissurables avant 2030. Si vous voulez que vos données soient en sécurité au-delà de cette période, choisissez une taille de clé supérieure à 4096..
 Les clés générées sont sous la forme de SecKey objets. Un problème avec l'implémentation d'Apple de SecKey est qu'il n'inclut pas toutes les informations essentielles qui constituent une clé publique. Il ne s'agit donc pas d'un certificat X.509 codé DER valide. L'ajout des informations manquantes dans le format d'une application iOS ou OS X, même sur des plates-formes côté serveur telles que PHP, nécessite un certain travail, qui implique de travailler dans un format appelé ASN.1. Heureusement, cela a été corrigé dans iOS 10 avec une nouvelle SecKey fonctions pour générer, exporter et importer des clés. 
Le code ci-dessous vous montre l’autre côté de la communication: la classe qui accepte une clé publique via SecKeyCreateWithData pour vérifier les fichiers à l'aide du SecKeyRawVerify une fonction.
@available (iOS 10.0, *) class FileVerifier private var publicKey: SecKey? func addPublicKey (_ keyString: String) -> Bool var success = false si let keyData = Data.init (base64Encoded: keyString) let paramètres: [Chaîne: AnyObject] = kSecAttrKeyType en tant que Chaîne: kSecAttrKeyTrac , kSecAttrKeySizeInBits en tant que String: 4096 en tant que AnyObject, kSecReturnPersistentRef en tant que String: true en tant que AnyObject] publicKey = SecKeyCreateWithData (keyData en tant que CFData, paramètres en tant que CFDictionary, nil) si (publicKey! = nil) succès = true retour succès _ chemin: chaîne, avec signature de signature: chaîne) -> Bool var success = false si (publicKey! = nil) si let fileData = FileManager.default.contents (atPath: chemin) si let signatureData = Data.init (base64Encoded : signature) // hash le message d'abord laisser digestLength = Int (CC_SHA512_DIGEST_LENGTH) laisser hashBytes = UnsafeMutablePointer.allocate (capacité: digestLength) CC_SHA512 ([UInt8] (fileData), CC_LONG (fileData.count), hashBytes) // vérifie let status = signatureData.withUnsafeBytes signatureBytes en retour SecKeyRawVerify (publicKey!, .PKC1SHA512, hashByboldes, , signatureData.count) if status == noErr succès = true else print ("Erreur de vérification de la signature") // - 9809: errSSLCrypto, etc return return
 Vous pouvez essayer ceci et vérifier que cela fonctionne en utilisant un test simple comme suit:
if #available (iOS 10.0, *) gardien let plistPath = Bundle.main.path (pour la ressource: "Info", ofType: "plist") else print ("Impossible d'obtenir un plist"); return let fileSigner = FileSigner () DispatchQueue.global (qos: .userInitiated) .async // La génération de clé RSA peut durer longtemps guard let publicKeyString = fileSigner.generateKeys () else print ("Erreur de génération de clé"); return // Retour au fil principal DispatchQueue.main.async guard let signature = fileSigner.signFile (plistPath) else print ("Pas de signature"); return // Enregistrer la signature à l'autre extrémité let fileVerifier = FileVerifier () guard fileVerifier.addPublicKey (publicKeyString) else print ("La clé n'a pas été ajoutée"); return let success = fileVerifier.verifyFile (plistPath, withSignature: signature) si success print ("Les signatures correspondent!") else print ("Les signatures ne correspondent pas.") 
Il y a un inconvénient à la génération de clé RSA, c'est lent! Le temps nécessaire pour générer les clés dépend de la taille de la clé. Sur les appareils plus récents, une clé de 4 096 bits ne prend que quelques secondes, mais si vous exécutez ce code sur un iPod Touch 4e génération, cela peut prendre environ une minute. C'est bien si vous générez les clés plusieurs fois sur un ordinateur, mais que se passe-t-il lorsque nous devons générer des clés fréquemment sur un appareil mobile? Nous ne pouvons pas simplement réduire la taille de la clé car cela dégrade la sécurité. 
Alors, quelle est la solution? Eh bien, la cryptographie à courbe elliptique (ECC) est une approche émergente, un nouvel ensemble d’algorithmes basés sur des courbes elliptiques sur des champs finis. Les clés ECC ont une taille beaucoup plus petite et sont plus rapides à générer que les clés RSA. Une clé de 256 bits seulement offre un très haut niveau de sécurité! Pour tirer parti d'ECC, nous n'avons pas besoin de changer beaucoup de code. Nous pouvons signer nos données en utilisant le même SecKeyRawSign fonction, puis ajustez les paramètres pour utiliser l'algorithme ECDSA (Elliptic Curve Digital Signature Algorithme). 
 Conseil: pour plus d’idées de mise en œuvre RSA, vous pouvez consulter la SwiftyRSA bibliothèque auxiliaire, qui se concentre sur le cryptage ainsi que sur la signature de messages.
 ECDSA
Imaginez le scénario suivant: une application de discussion en ligne permet aux utilisateurs de s'échanger des messages privés, mais vous voulez vous assurer qu'un adversaire n'a pas modifié le message lors de son acheminement vers l'autre utilisateur. Voyons comment vous pouvez sécuriser leur communication avec la cryptographie. 
Tout d'abord, chaque utilisateur génère une paire de clés de clés publiques et privées sur son appareil mobile. Leurs clés privées sont stockées dans la mémoire et ne quittent jamais l'appareil, tandis que les clés publiques sont transmises les unes aux autres. Comme auparavant, la clé privée est utilisée pour signer les données envoyées, tandis que la clé publique est utilisée pour la vérification. Si un attaquant capturait une clé publique lors du transit, il ne lui restait plus qu'à vérifier l'intégrité du message d'origine envoyé par l'expéditeur. Un attaquant ne peut pas altérer un message car il ne dispose pas de la clé privée nécessaire pour reconstruire la signature..
 Il existe un autre avantage à utiliser ECDSA sur iOS. Nous pouvons utiliser le fait qu’à présent, les clés à courbe elliptique sont les seules pouvant être stockées dans l’enclave sécurisée de l’appareil. Toutes les autres clés sont stockées dans le trousseau qui crypte ses éléments dans la zone de stockage par défaut du périphérique. Sur les périphériques qui en ont un, l'enclave sécurisé est séparé du processeur et le stockage des clés est implémenté dans le matériel sans accès direct au logiciel. L'enclave sécurisée peut stocker une clé privée et l'utiliser pour produire une sortie envoyée à votre application sans jamais exposer la clé privée réelle en la chargeant en mémoire.!
J'ajouterai un support pour la création de la clé privée ECDSA sur l'enclave sécurisée en ajoutant le kSecAttrTokenIDSecureEnclave option pour le kSecAttrTokenID paramètre. Nous pouvons commencer cet exemple avec un Utilisateur objet qui générera une paire de clés lors de l'initialisation.
 @available (iOS 9.0, *) class User public var publicKeyKey: SecKey? private var privateKey: SecKey? destinataire var privé: utilisateur? init (withUserID id: String) // si let access = SecAccessControlCreateWithFlags (nil, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, [.privateKeyUsage / *, .userPresence] authentification UI pour obtenir la clé privée * /], page suivante Touch ID set up… si laissez access = SecAccessControlCreateWithFlags (nil, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, [.privateKeyUsage], nil) // Conserve la clé privée sur le périphérique let privateTagString = "com.example.privateKey". + id let privateTag = privateTagString.data (en utilisant: .utf8)! // Stockez-le en tant que données, et non en tant que chaîne, laissez privateKeyParameters: [String: AnyObject] = [kSecAttrIsPermanent en tant que chaîne: true en tant que AnyObject, kSecAttrAccessControl en tant que chaîne: accès en tant que AnyObject, kSecAttrApplicationTag en tant que chaîne,: privateTag en tant que AnyObject] com.example.publicKey. " + id let publicTag = publicTagString.data (en utilisant: .utf8)! // Données, pas String let publicKeyParameters: [String: AnyObject] = [kSecAttrIsPermanent as String: false comme AnyObject, kSecAttrApplicationTag as String, publicTag comme AnyObject,] let keyPairParameters: [String: AnyObject] = [kSecAtKey La qualité est la meilleure if status! = noErr print ("Erreur de génération de clé") //… 
 Ensuite, nous allons créer des fonctions d’aide et des exemples. Par exemple, la classe permettra à un utilisateur d’engager une conversation et d’envoyer un message. Bien sûr, dans votre application, vous souhaitez configurer cela pour inclure votre configuration réseau spécifique..
 //… private func sha512Digest (pour les données de données: Données) -> Données let len = Int (CC_SHA512_DIGEST_LENGTH) let digest = UnsafeMutablePointer.allocate (capacité: len) CC_SHA512 ((data en tant que NSData) .bytes, CC_LONG (data.count), digest) renvoie NSData (bytesNoCopy: UnsafeMutableRawPointer (condensé, longueur: len) en tant que Data public func initiConversation (avecUser user: utilisateur ) -> Bool var success = false si publicKey! = Nil utilisateur.receiveInitialization (auto) destinataire = utilisateur success = true retourne succès fonction publique receiveInitialization (_ utilisateur: Utilisateur) destinataire = utilisateur fonction publique sendMessage (_ message: String) if let data = message.data (using: .utf8) let signature = self.signData (plainText: data) if signature! = nil self.recipient? .receiveMessage (message, withSignature: signature!)  public func receiveMessage (_ message: String, signature Signature: Données) let signatureMatch = verifySignature (plainText: message.data (using: .utf8) !, signature: signature) si signatureMatch print ("Message reçu. Signature vérifié. Le message est: ", message) else print (" Message reçu. Erreur de signature. ") //… 
Ensuite, nous ferons la signature et la vérification. ECDSA, contrairement à RSA, n'a pas besoin d'être haché avant la signature. Cependant, si vous voulez avoir une fonction permettant de facilement échanger l'algorithme sans apporter beaucoup de modifications, il est alors tout à fait correct de continuer à hacher les données avant de signer..
 //… func signData (plainText: Data) -> Data? guard privateKey! = nil else print ("Clé privée indisponible") retourne nil let digestToSign = self.sha512Digest (forData: plainText) let signature = UnsafeMutablePointer.allocate (capacité: 512) // 512 - surcharge var signatureLength = 512 let status = SecKeyRawSign (privateKey !, .PKCS1SHA512, [UInt8] (digestToSign), Int (CC_SHA512_DIGEST_LENGTH), signature, & signatureLength) si statut! = noErr print "Signature fail: \ (status)") return Data.init (octets: signature, count: signatureLength) // redimensionnement à la taille réelle de la signature func verifySignature (plainText: Data, signature: Data) -> Bool Guard destinataire? .publicKey! = nil else print ("La clé publique de destinataire n'est pas disponible") return false let digestToVerify = self.sha512Digest (forData: plainText) let signedHashBytesSize = signature.count let status = SecKeyRawVerify (destinataire! .publicKey !, .PKCS1SHA512, [UInt8] (digestToVerify), Int (CC_SHA512_DIGEST_LENGTH), [UInt8] (signature en tant que données), signedHashBytesSize) renvoie le statut == noErr.
 Ceci vérifie le message, ainsi que l’identité d’un utilisateur spécifique puisque seul cet utilisateur est en possession de sa clé privée.. 
Cela ne signifie pas que nous connectons la clé à l'identité réelle de l'utilisateur. Le problème de la correspondance d'une clé publique avec un utilisateur spécifique est un autre domaine. Les solutions n'entrant pas dans le cadre de ce didacticiel, les applications de chat sécurisé telles que Signal et Telegram permettent aux utilisateurs de vérifier une empreinte digitale ou un numéro via un canal de communication secondaire. De même, Pidgin propose un système de questions-réponses dans lequel vous posez une question que seul l'utilisateur doit connaître. Ces solutions ouvrent tout un monde de débats sur la meilleure approche à adopter..
Cependant, notre solution cryptographique vérifie que le message ne peut avoir été envoyé que par une personne possédant une clé privée spécifique..
Faisons un test simple de notre exemple:
if #available (iOS 9.0, *) let alice = User.init (withUserID: "aaaaaa1") let bob = User.init (withUserID: "aaaaaa2") acceptera = alice.initiateConversation (withUser: bob) si (accepté ) alice.sendMessage ("Bonjour ici") bob.sendMessage ("Message de test") alice.sendMessage ("Un autre message de test")
OAuth et SSO
 Lorsque vous travaillez avec des services tiers, vous remarquerez souvent d'autres termes de haut niveau utilisés pour l'authentification, tels que OAuth et SSO. Bien que ce tutoriel concerne la création d’une signature, j’expliquerai brièvement la signification des autres termes..
 OAuth est un protocole d'authentification et d'autorisation. Il sert d'intermédiaire pour utiliser le compte d'une personne pour des services tiers et vise à résoudre le problème de l'autorisation sélective de l'accès à vos données. Si vous vous connectez au service X via Facebook, un écran vous demande, par exemple, si le service X est autorisé à accéder à vos photos Facebook. Pour ce faire, il fournit un jeton sans révéler le mot de passe de l'utilisateur..
 L'authentification unique, ou SSO, décrit le processus par lequel un utilisateur authentifié peut utiliser ses mêmes informations de connexion pour accéder à plusieurs services. Un exemple de cela est le fonctionnement de votre compte Gmail pour vous connecter à YouTube. Si vous avez plusieurs services dans votre entreprise, vous ne voudrez peut-être pas créer des comptes d’utilisateur distincts pour tous les services..
 Conclusion
Dans ce tutoriel, vous avez vu comment créer des signatures en utilisant les normes les plus courantes. Maintenant que nous avons couvert tous les concepts principaux, récapitulons!
 Utilisez HMAC lorsque vous avez besoin de rapidité et que vous êtes sûr que la clé secrète peut être échangée en toute sécurité..
 Si les clés doivent voyager sur un réseau, il est préférable d'utiliser RSA ou ECDSA..
 RSA est toujours le standard le plus populaire. Son étape de vérification est assez rapide. Utilisez RSA si le reste de votre équipe connaît déjà ou utilise le standard..
 Toutefois, si vous devez générer des clés sur un périphérique lent, utilisez ECDSA. Bien que la vérification ECDSA soit un peu plus lente que la vérification RSA, cela ne se compare pas aux nombreuses secondes économisées sur RSA pour la génération de clé.
 
Voilà pour les signatures numériques dans Swift. Si vous avez des questions, n'hésitez pas à m'envoyer un message dans la section commentaires, et en attendant, consultez certains de nos autres tutoriels sur la sécurité des données et le développement d'applications dans Swift.!





		
			
	   
	




Code