Toutes les connexions entre les clients TeamViewer utilisent des certificats pour authentifier l'identité des deux participants. Ces certificats sont délivrés par l'autorité de certification TeamViewer pour chaque ID TeamViewer et empêchent les appareils d'usurper l'identité d'un autre. La fonction "Bring Your Own Certificate" (BYOC) permet aux utilisateurs de TeamViewer d'utiliser leurs propres certificats pour authentifier les appareils impliqués dans une connexion TeamViewer. Cette fonction est indépendante de l'authentification des certificats TeamViewer et s'y ajoute toujours.

Les installations de TeamViewer peuvent être configurées de manière à exiger une authentification par certificat personnalisé pour les connexions entrantes, les connexions sortantes ou les deux. Lorsque l'authentification par certificat personnalisé est requise, la connexion ne peut aboutir que si l'autre partie dispose d'une clé privée pour un certificat signé par l'autorité de certification configurée. Il s'agit d'un moyen efficace de limiter les connexions TeamViewer à un ensemble spécifique d'appareils.

Certificats

L'utilisation du BYOC exige qu'une seule autorité de certification (AC) signe les certificats de tous les appareils qui doivent s'authentifier. Tous les appareils qui nécessitent une authentification par certificat de la part d'autres appareils doivent avoir accès au certificat de l'autorité de certification. Tous les appareils qui souhaitent s'authentifier auprès d'autres appareils doivent avoir accès à un certificat signé par l'autorité de certification, à la clé privée correspondante et à tous les certificats intermédiaires (le cas échéant). TeamViewer prend en charge les certificats X.509 et peut les importer, ainsi que leurs clés privées, soit à partir de fichiers, soit à partir du magasin de confiance Windows.

Utilisation du Magasin de certificats de Windows

Les certificats et les clés privées chargés à partir du magasin de certificats (Trust Store) Windows doivent être installés dans le magasin de certificats de l'ensemble de la machine. Ce magasin est accessible à l'aide de certlm.msc.

Le certificat de l'autorité de certification doit être installé dans le répertoire "Trusted Root Certification Authorities". Le certificat d'autorité de certification spécifique utilisé pour l'authentification est identifié par son empreinte digitale unique, codée en hexadécimal. L'empreinte digitale peut être trouvée comme "Thumbprint" à l'intérieur de l'onglet "Details" en double-cliquant sur le certificat désiré.

Le certificat de l'appareil doit être installé dans le répertoire "Personal" des certificats de l'ordinateur local. Il doit disposer d'une clé privée, ce qui peut être vérifié en double-cliquant sur le certificat, où une petite icône de clé s'affiche.

Pour plus de commodité, la fonction BYOC peut être configurée de manière à utiliser le certificat client portant le même nom que la machine locale. Cela permet d'utiliser la même configuration pour toutes les machines et c'est la manière recommandée de configurer les certificats clients.

Utilisation des fichiers de certificats

Les certificats et les clés privées chargés à partir de fichiers doivent être soit des X.509 binaires encodés en DER, soit des X.509 encodés en base-64 (format PEM). D'autres formats tels que PFX ne sont pas pris en charge.

S'il existe des certificats intermédiaires entre l'appareil et les certificats racine, ils doivent être inclus dans le fichier de certificat de l'appareil. Cela n'est possible qu'avec les fichiers au format PEM ; les fichiers au format DER ne peuvent pas contenir de chaînes de certificats.

Le fichier contenant la clé privée doit être suffisamment protégé par les contrôles d'accès du système d'exploitation. Si le service TeamViewer est en cours d'exécution, il accèdera à la clé privée, de sorte que sur Windows, seul l'accès de l'utilisateur SYSTEM est requis.

Configuration

Par défaut, la fonction BYOC est désactivée et aucune connexion entrante ou sortante ne nécessite d'authentification par certificat. Inversement, il n'est pas non plus possible de se connecter ou de recevoir des connexions d'une machine nécessitant une authentification par certificat.

Pour activer la fonction BYOC et exiger l'authentification par certificat, une chaîne de configuration doit être placée dans les paramètres de TeamViewer. Ces derniers se trouvent dans le registre . Ceux-ci se trouvent dans le registre Windows. L'emplacement exact dépend de la combinaison des versions 32 bits ou 64 bits de Windows et TeamViewer utilisées :

La configuration du BYOC se trouve dans la sous-clé "Sécurité". Cette clé de registre doit être créée si elle n'existe pas encore. Ensuite, pour activer la fonction BYOC, il faut créer une nouvelle valeur de type "String" et nommée "BYOC_Configuration".

Si cette valeur existe et n'est pas vide, la fonction BYOC est active, même si la configuration n'est pas valide. Si la configuration n'est pas valide, aucune connexion ne sera possible.

PowerShell peut être utilisé pour créer cette valeur à partir de la ligne de commande :

New-Item -Force `
         -Path HKLM:\SOFTWARE\TeamViewer\Security
New-ItemProperty -Force `
                 -Path HKLM:\SOFTWARE\TeamViewer\Security `
                 -Name BYOC_Configuration

La configuration elle-même utilise le format JSON. Le JSON peut être tapé directement ou copié dans l'éditeur de registre, mais l'interface utilisateur ne permet qu'une seule ligne, de sorte que le JSON doit être dépouillé de toutes les nouvelles lignes. La clé de registre peut également être définie à partir d'un fichier via PowerShell. En supposant que la configuration soit enregistrée dans un fichier appelé TeamViewerBYOC.json dans le répertoire actuel, elle peut être chargée comme suit :

New-ItemProperty -Force `
                 -Path HKLM:\SOFTWARE\TeamViewer\Security `
                 -Name BYOC_Configuration `
                 -Value $(Get-Content TeamViewerBYOC.json)

Le contenu du JSON détermine quand l'authentification par certificat est requise et où trouver les certificats. Les sections suivantes présentent quelques exemples de configuration.

Utilisation du Magasin de certificats de Windows

Les certificats et les clés privées peuvent être chargés à partir du magasin de certificats de la machine Windows. Pour identifier le bon certificat, le client TeamViewer peut rechercher un certificat portant le même nom que la machine locale. Ce certificat est appelé certificat host dans le présent document.

La configuration pour charger le certificat host ressemble à ceci :

{
 "cert": {
  "windows": {
   "use_host_certificate": true
  }
 }
}

Cela permettra d'utiliser le certificat host pour s'authentifier sur ce périphérique et d'utiliser l'autorité de certification qui a signé le certificat host pour authentifier d'autres périphériques. En identifiant le certificat correct par le nom d'hôte, cette configuration peut être utilisée sur différents appareils et utiliser le certificat spécifique à l'appareil.

Il est également possible de spécifier explicitement le certificat de l'autorité de certification par le biais de son empreinte digitale :

{
 "cert": {
  "windows": {
   "use_host_certificate": true
  }
 },
 "root_ca": {
  "windows": {
   "fingerprint": "d2dcdd02666b6335736c137fbbecff84730837af"
  }
 }
}

Utilisation des fichiers de certificats

Les certificats peuvent également être chargés à partir de fichiers. Pour le certificat client, la clé doit également être disponible sous forme de fichier, au même format (PEM ou DER) que le certificat lui-même. Seul le service TeamViewer doit avoir accès à la clé ; sur Windows, ce processus s'exécute sous l'utilisateur SYSTEM. Il est recommandé de limiter l'accès au fichier de la clé privée.

S'il existe des certificats intermédiaires, ils doivent être ajoutés au fichier de certificats du client. Dans ce cas, un fichier PEM doit être utilisé ; il n'est pas possible d'utiliser une chaîne de certificats avec des fichiers DER.

La configuration pour charger les fichiers PEM se présente comme suit :

{
 "cert": {
  "pem": {
   "path": "/etc/teamviewer/certs/client_chain.pem",
   "key_path": "/etc/teamviewer/certs/client.key"
  }
 },
 "root_ca": {
  "pem": {
   "path": "/etc/teamviewer/certs/ca.pem"
  }
 }
}

Sinon, pour charger des fichiers binaires DER, il faut procéder comme suit :

{
 "cert": {
  "der": {
   "path": "/etc/teamviewer/certs/client.der",
   "key_path": "/etc/teamviewer/certs/client.key"
  }
 },
 "root_ca": {
  "der": {
   "path": "/etc/teamviewer/certs/ca.der"
  }
 }
}

Désactivation de la vérification des certificats

Par défaut, l'authentification est requise pour les connexions entrantes et sortantes. Celles-ci peuvent être désactivées individuellement dans la section root_ca.

Pour n'exiger des certificats que pour les connexions entrantes :

{
 "cert": {
  ...
 },
 "root_ca": {
  "dont_validate_outgoing": true
 }
}

Il est également possible d'exiger des certificats uniquement pour les connexions sortantes :

{
 "cert": {
  ...
 },
 "root_ca": {
  "dont_validate_incoming": true
 }
}

Les deux options peuvent être combinées pour ne pas exiger d'authentification de certificat pour les connexions entrantes ou sortantes. Cela peut s'avérer utile, car cela permet au client de s'authentifier auprès d'autres appareils qui requièrent une authentification par certificat.

Sécurité améliorée grâce à la vérification de la révocation des certificats à l'aide des LCR

En outre, une fonction de sécurité renforcée permet de vérifier les certificats à l'aide des listes de révocation de certificats (CRL), si elles sont prises en charge. Par défaut, l'option de vérification des LCR n'est pas activée. Cela signifie qu'en plus des méthodes existantes, il existe désormais un mécanisme permettant de révoquer et de superviser les certificats à l'aide de LCR (listes de révocation de certificats).

{ 
"cert": { 
... 
}, 
"root_ca": { 
"verify_crl": true 
} 
} 

(Dans cette section, le certificat émetteur fait référence au certificat RootCA ou aux certificats IntermediateCA, qui émettent le certificat suivant dans la chaîne. Par exemple, RootCA ➜ IntermediateCA ➜ Client, RootCA émet IntermediateCA et IntermediateCA émet RootCA)

(Dans cette section, le certificat délivré fait référence aux certificats IntermediateCA ou aux certificats clients, qui sont délivrés par le certificat précédent dans la chaîne. Par exemple, RootCA ➜ IntermediateCA ➜ Client, IntermediateCA est délivré par RootCA, et Client est délivré par IntermediateCA).

Tout certificat émetteur peut révoquer un certificat émis pour des raisons qui sont mises à jour dans la CRL avec le numéro de série du certificat révoqué.

La CRL est téléchargée à partir d'une URL disponible dans le certificat en tant que point de distribution de CRL. Les certificats sont autorisés à prendre en charge plusieurs URL dans les points de distribution de CRL, et donc plusieurs CRL pour un certificat. Les CRL au format PEM et DER sont prises en charge. Pour l'instant, seules les CRL de base sont prises en charge ; il n'y a pas de prise en charge des CRL delta.

Comment s'effectue la vérification des certificats ?

Pour une chaîne de certificats, qu'il s'agisse de RootCA ➜ Client ou de RootCA ➜ IntermediateCA ➜ Client, pour chaque certificat émis, les CRL sont téléchargées via des points de distribution (URL). Les certificats émis sont ensuite vérifiés par rapport aux CRL.

La vérification échoue et, par conséquent, l'authentification échoue dans l'un des scénarios suivants :

  • si une chaîne de certificats n'est pas vérifiable ou si les certificats ont expiré
  • si une URL n'est pas accessible ou ne permet pas de télécharger la CRL
  • si une CRL n'est pas dans le bon format de CRL, s'il s'agit d'un fichier vide ou s'il manque des octets
  • si une CRL a expiré
  • si la CRL n'est pas générée par le certificat émetteur d'un certificat URL
  • si un certificat délivré est révoqué

Limites

Cette fonctionnalité est encore en cours de développement et présente quelques limitations connues à ce jour :

  • Les réunions ne sont, par définition, pas couvertes par les restrictions BYOC.
  • Cette fonction n'est actuellement compatible qu'avec Windows.