RS256 vs HS256: Quelle est la différence?

J'utilise Auth0 pour gérer l'authentification dans mon application Web. J'utilise ASP.NET Core v1.0.0 et Angular 2 rc5 et je ne connais pas grand-chose à l'authentification / sécurité en général.

Dans les documents Auth0 pour ASP.NET Core Web Api , l'algorithme JWT est RS256 et HS256. Cela peut être une question stupide mais:

Quelle est la différence entre RS256 et HS256? Quels sont certains cas d'utilisation (le cas échéant)?

Les deux choix font référence à l'algorithme utilisé par le fournisseur d'identité pour signer le JWT. La signature est une opération cryptographique qui génère une "signature" (partie du JWT) que le destinataire du jeton peut valider pour s'assurer que le jeton n'a pas été falsifié.

• RS256 (signature RSA avec SHA-256 ) est un algorithme asymétrique , et il utilise une paire de clés publique / privée: le fournisseur d'identité a une clé privée (secrète) utilisée pour générer la signature, et le consommateur du JWT obtient une clé publique pour valider la signature. Étant donné que la clé publique, contrairement à la clé privée, n'a pas besoin d'être sécurisée, la plupart des fournisseurs d'identité la rendent facilement accessible et utilisable par les consommateurs (généralement via une URL de métadonnées).

• HS256 ( HMAC avec SHA-256), d'autre part, implique une combinaison d'une fonction de hachage et d'une clé (secrète) qui est partagée entre les deux parties utilisées pour générer le hachage qui servira de signature. Étant donné que la même clé est utilisée à la fois pour générer la signature et pour la valider, il faut veiller à ce que la clé ne soit pas compromise.

Si vous développez l'application consommant les JWT, vous pouvez utiliser le HS256 en toute sécurité, car vous aurez le contrôle sur qui utilise les clés secrètes. Si, en revanche, vous n'avez pas de contrôle sur le client, ou si vous n'avez aucun moyen de sécuriser une clé secrète, RS256 conviendra mieux, car le consommateur n'a besoin que de connaître la clé publique (partagée).

Étant donné que la clé publique est généralement disponible à partir des points de terminaison de métadonnées, les clients peuvent être programmés pour récupérer la clé publique automatiquement. Si tel est le cas (comme c'est le cas avec les bibliothèques .Net Core), vous aurez moins de travail à faire sur la configuration (les bibliothèques chercheront la clé publique sur le serveur). Les clés symétriques, en revanche, doivent être échangées hors bande (garantissant un canal de communication sécurisé) et mises à jour manuellement en cas de roulement de clé de signature.

Auth0 fournit des points de terminaison de métadonnées pour les protocoles OIDC, SAML et WS-Fed, où les clés publiques peuvent être récupérées. Vous pouvez voir ces points de terminaison sous les "Paramètres avancés" d'un client.

Le point de terminaison des métadonnées OIDC, par exemple, prend la forme de https://{account domain}/.well-known/openid-configuration. Si vous accédez à cette URL, vous verrez un objet JSON avec une référence à https://{account domain}/.well-known/jwks.json, qui contient la clé publique (ou les clés) du compte.

Si vous regardez les exemples RS256, vous verrez que vous n'avez pas besoin de configurer la clé publique n'importe où: elle est récupérée automatiquement par le framework.

En cryptographie, deux types d'algorithmes sont utilisés:

Algorithmes symétriques

Une seule clé est utilisée pour crypter les données. Une fois chiffrées avec la clé, les données peuvent être déchiffrées à l'aide de la même clé. Si, par exemple, Mary crypte un message à l'aide de la clé "my-secret" et l'envoie à John, il pourra décrypter le message correctement avec la même clé "my-secret".

Algorithmes asymétriques

Deux clés sont utilisées pour crypter et décrypter les messages. Alors qu'une clé (publique) est utilisée pour crypter le message, l'autre clé (privée) ne peut être utilisée que pour le décrypter. Ainsi, John peut générer des clés publiques et privées, puis envoyer uniquement la clé publique à Mary pour crypter son message. Le message ne peut être déchiffré qu'à l'aide de la clé privée.

Scénario HS256 et RS256

Ces algorithmes ne sont PAS utilisés pour crypter / décrypter les données. Ils sont plutôt utilisés pour vérifier l'origine ou l'authenticité des données. Lorsque Mary doit envoyer un message ouvert à Jhon et qu'il doit vérifier que le message provient bien de Mary, HS256 ou RS256 peuvent être utilisés.

Le HS256 peut créer une signature pour un échantillon de données donné à l'aide d'une seule clé. Lorsque le message est transmis avec la signature, le destinataire peut utiliser la même clé pour vérifier que la signature correspond au message.

RS256 utilise une paire de clés pour faire de même. Une signature ne peut être générée qu'à l'aide de la clé privée. Et la clé publique doit être utilisée pour vérifier la signature. Dans ce scénario, même si Jack trouve la clé publique, il ne peut pas créer un message d'usurpation d'identité avec une signature pour usurper l'identité de Mary.

Il y a une différence de performances.

Autrement dit, il HS256est environ 1 ordre de grandeur plus rapide que RS256pour la vérification, mais environ 2 ordres de grandeur plus rapide que RS256pour l'émission (signature).

 640,251  91,464.3 ops/s
  86,123  12,303.3 ops/s (RS256 verify)
   7,046   1,006.5 ops/s (RS256 sign)

Ne vous attardez pas sur les chiffres réels, pensez-y simplement avec respect l'un pour l'autre.

[Program.cs]

class Program
{
    static void Main(string[] args)
    {
        foreach (var duration in new[] { 1, 3, 5, 7 })
        {
            var t = TimeSpan.FromSeconds(duration);

            byte[] publicKey, privateKey;

            using (var rsa = new RSACryptoServiceProvider())
            {
                publicKey = rsa.ExportCspBlob(false);
                privateKey = rsa.ExportCspBlob(true);
            }

            byte[] key = new byte[64];

            using (var rng = new RNGCryptoServiceProvider())
            {
                rng.GetBytes(key);
            }

            var s1 = new Stopwatch();
            var n1 = 0;

            using (var hs256 = new HMACSHA256(key))
            {
                while (s1.Elapsed < t)
                {
                    s1.Start();
                    var hash = hs256.ComputeHash(privateKey);
                    s1.Stop();
                    n1++;
                }
            }

            byte[] sign;

            using (var rsa = new RSACryptoServiceProvider())
            {
                rsa.ImportCspBlob(privateKey);

                sign = rsa.SignData(privateKey, "SHA256");
            }

            var s2 = new Stopwatch();
            var n2 = 0;

            using (var rsa = new RSACryptoServiceProvider())
            {
                rsa.ImportCspBlob(publicKey);

                while (s2.Elapsed < t)
                {
                    s2.Start();
                    var success = rsa.VerifyData(privateKey, "SHA256", sign);
                    s2.Stop();
                    n2++;
                }
            }

            var s3 = new Stopwatch();
            var n3 = 0;

            using (var rsa = new RSACryptoServiceProvider())
            {
                rsa.ImportCspBlob(privateKey);

                while (s3.Elapsed < t)
                {
                    s3.Start();
                    rsa.SignData(privateKey, "SHA256");
                    s3.Stop();
                    n3++;
                }
            }

            Console.WriteLine($"{s1.Elapsed.TotalSeconds:0} {n1,7:N0} {n1 / s1.Elapsed.TotalSeconds,9:N1} ops/s");
            Console.WriteLine($"{s2.Elapsed.TotalSeconds:0} {n2,7:N0} {n2 / s2.Elapsed.TotalSeconds,9:N1} ops/s");
            Console.WriteLine($"{s3.Elapsed.TotalSeconds:0} {n3,7:N0} {n3 / s3.Elapsed.TotalSeconds,9:N1} ops/s");

            Console.WriteLine($"RS256 is {(n1 / s1.Elapsed.TotalSeconds) / (n2 / s2.Elapsed.TotalSeconds),9:N1}x slower (verify)");
            Console.WriteLine($"RS256 is {(n1 / s1.Elapsed.TotalSeconds) / (n3 / s3.Elapsed.TotalSeconds),9:N1}x slower (issue)");

            // RS256 is about 7.5x slower, but it can still do over 10K ops per sec.
        }
    }
}

réponse courte, spécifique à OAuth2,

• Secret client utilisateur HS256 pour générer la signature de jeton et le même secret est requis pour valider le jeton en back-end. Vous devez donc avoir une copie de ce secret sur votre serveur principal pour vérifier la signature.
• RS256 utilise le cryptage à clé publique pour signer le jeton. La signature (hachage) crée à l'aide d'une clé privée et peut vérifier à l'aide de la clé publique. Ainsi, pas besoin de clé privée ou de secret client à stocker sur le serveur principal, mais le serveur principal récupérera la clé publique de l'URL de configuration openid dans votre client ( https: // [tenant] /.well-known/openid -configuration ) pour vérifier le jeton. Le paramètre KID à l'intérieur de access_toekn utilisera pour détecter la bonne clé (publique) de la configuration openid.