FR3136073A1 - Procédé d’envoi sécurisé d’un courrier électronique - Google Patents

Procédé d’envoi sécurisé d’un courrier électronique Download PDF

Info

Publication number
FR3136073A1
FR3136073A1 FR2204976A FR2204976A FR3136073A1 FR 3136073 A1 FR3136073 A1 FR 3136073A1 FR 2204976 A FR2204976 A FR 2204976A FR 2204976 A FR2204976 A FR 2204976A FR 3136073 A1 FR3136073 A1 FR 3136073A1
Authority
FR
France
Prior art keywords
user
server
electronic mail
email
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR2204976A
Other languages
English (en)
Other versions
FR3136073B1 (fr
Inventor
Jon Doyle
Tanguy GODQUIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mailspec SAS
Original Assignee
Mailspec SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mailspec SAS filed Critical Mailspec SAS
Priority to FR2204976A priority Critical patent/FR3136073B1/fr
Priority to US18/316,950 priority patent/US20230388300A1/en
Publication of FR3136073A1 publication Critical patent/FR3136073A1/fr
Application granted granted Critical
Publication of FR3136073B1 publication Critical patent/FR3136073B1/fr
Priority to US19/279,907 priority patent/US20250358281A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1483Countermeasures against malicious traffic service impersonation, e.g. phishing, pharming or web spoofing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/212Monitoring or handling of messages using filtering or selective blocking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083Network architectures or network communication protocols for network security for authentication of entities using passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/18Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L’invention se rapporte à un procédé d’envoi sécurisé (200a) d’un courrier électronique, le procédé (200a) comprenant : recevoir au niveau d’un serveur de messagerie électronique (102) une requête provenant d’un utilisateur pour envoyer le courrier électronique, l’utilisateur ayant un compte de messagerie électronique sur le serveur de messagerie électronique (102), l’utilisateur s’étant préalablement identifié au compte de messagerie électronique ; en réponse à la réception de la requête, envoyer par le serveur (102) un test de sécurité à compléter par l’utilisateur à un appareil de confiance (104) associé à l’utilisateur via un canal sécurisé ; recevoir le test de sécurité complété par l’utilisateur au serveur (102) via le canal sécurisé ; valider le test de sécurité complété par l’utilisateur par le serveur (102); et envoyer le courrier électronique par le serveur (102) si le test est validé par l’utilisateur. Figure pour l’abrégé : Fig. 1

Description

Procédé d’envoi sécurisé d’un courrier électronique DOMAINE DE L’INVENTION
Le domaine technique de la présente invention concerne l’envoi et la réception sécurisé de courriers électroniques.
L’envoi et la réception de courriers électroniques sont régis par plusieurs protocoles : SMTP permettant l’envoi d’un courrier et POP et IMAP permettant de rapatrier le courrier pour être lu par un utilisateur. Un client de messagerie (MUA) de l’expéditeur envoie par SMTP le courrier électronique à un serveur. Le serveur route le message vers le serveur du destinataire. Le serveur du destinataire délivre à un MDA (Mail Delivery Agent) qui est chargé de la gestion des boîtes emails. Le destinataire, par l’intermédiaire de son MUA, demande au MDA les nouveaux messages via l’utilisation des protocoles IMAP ou POP. Le serveur envoie le message au MUA du destinataire.
Cependant, les protocoles utilisés pour l’envoi et la réception des courriers électroniques ont été inventés avant l’utilisation de l’Internet à haut débit. De plus, il existe de nombreux types de courriers électroniques provenant de différents services de messageries électroniques. Pour cette raison il est difficile de sécuriser l’envoi et la réception de courriers électroniques.
De plus, les services de messageries électroniques nécessitent l’authentification par un nom d’utilisateur et un mot de passe. Cependant, si le nom d’utilisateur et le mot de passe sont obtenus par une personne autre que l’utilisateur, par exemple, lors de l’emploi de mots de passe simples à deviner, d’autres utilisateurs peuvent envoyer des courriers électroniques malveillants ou accéder à des données confidentielles.
L’invention vient améliorer la situation en proposant un procédé d’envoi sécurisé de courriers électroniques. En effet, la présente invention propose une double authentification permettant de s’assurer que l’utilisateur associé à un service de messagerie est également l’utilisateur envoyant un courrier électronique depuis ce même service de messagerie.
De plus, il est noté que les protocoles utilisés pour l’envoi et la réception des courriers électroniques, dû à l’ancienneté de cette technologie, inclus un délai entre le moment où un utilisateur souhaite envoyer un courrier électronique (par exemple, en cliquant sur « envoyer ») et le moment où celui-ci est envoyé. Ainsi, le procédé décrit dans la présente demande tire avantage de ce délai car une authentification peut être réalisée pendant ce délai.
De façon similaire, un procédé de réception sécurisé de courriers électroniques est également décrit, utilisant également une double authentification permettant de s’assurer que l’utilisateur associé à un service de messagerie est également l’utilisateur recevant un courrier électronique depuis ce même service de messagerie.
Ainsi, l’invention vient améliorer la situation en proposant un procédé d’envoi sécurisé d’un courrier électronique, le procédé comprenant : recevoir au niveau d’un serveur de messagerie électronique une requête provenant d’un utilisateur pour envoyer le courrier électronique, l’utilisateur ayant un compte de messagerie électronique sur le serveur de messagerie électronique, l’utilisateur s’étant préalablement identifié au compte de messagerie électronique ; en réponse à la réception de la requête, envoyer par le serveur un test de sécurité à compléter par l’utilisateur à un appareil de confiance associé à l’utilisateur via un canal sécurisé ; recevoir le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé ; vérifier le test de sécurité complété par l’utilisateur par le serveur ; et envoyer le courrier électronique par le serveur si le test est validé par l’utilisateur.
De plus, l’invention vient améliorer la situation en proposant un procédé d’envoi sécurisé d’un courrier électronique, le procédé comprenant : recevoir, à un appareil de confiance associé à l’utilisateur en réponse à la réception d’une requête de transmission d’un courrier électronique par un serveur, un test de sécurité à compléter par l’utilisateur via un canal sécurisé ; compléter le test de sécurité par l’utilisateur sur l’appareil de confiance ; transmettre le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé pour validation et transmission du courrier électronique par le serveur si le test est validé par l’utilisateur.
De plus, l’invention vient améliorer la situation en proposant un procédé de détection d’une requête pour l’envoi d’un courrier électronique, le procédé comprenant : recevoir au niveau d’un serveur de messagerie électronique une requête provenant d’un utilisateur pour envoyer le courrier électronique, l’utilisateur ayant un compte de messagerie électronique sur le serveur de messagerie électronique, l’utilisateur s’étant préalablement identifié au compte de messagerie électronique; en réponse à la réception de la requête, envoyer par le serveur un test de sécurité à compléter par l’utilisateur à un appareil de confiance associé à l’utilisateur via un canal sécurisé ; recevoir le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé ; vérifier le test de sécurité complété par l’utilisateur par le serveur ; et rejeter le courrier électronique ou l’envoyer par le serveur à un autre destinataire que celui précisé dans le message si le test n’est pas validé par l’utilisateur.
Dans un mode de réalisation, le procédé comprend en outre : recevoir au niveau du serveur de messagerie électronique une autre requête provenant de l’utilisateur pour envoyer un autre courrier électronique ; vérifier un paramètre de sécurité prédéterminé ; envoyer le courrier électronique par le serveur si le paramètre de sécurité prédéterminé est satisfait.
Dans un mode de réalisation, le paramètre de sécurité comprenant : un temps écoulé entre l’envoie de la requête et de l’autre requête, un changement d’adresse IP utilisée par l’utilisateur et une date à laquelle la requête est envoyée par l’utilisateur.
Dans un mode de réalisation, le test de sécurité comprend une comparaison d’une entrée biométrique avec des données biométriques associées à l’utilisateur et stockées sur l’appareil de confiance associé à l’utilisateur.
Dans un mode de réalisation, l’appareil de confiance associé à l’utilisateur est un téléphone portable ou une clé USB.
Dans un mode de réalisation, l’appareil de confiance comprend une application permettant de compléter le test de sécurité.
De plus l’invention vient à améliorer la situation en proposant un produit-programme d’ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, amènent l'ordinateur à mettre en œuvre les procédés décrits ci-dessus.
De plus, l’invention vient à améliorer la situation en proposant un serveur permettant l’envoi sécurisé d’un courrier électronique, le serveur étant configuré pour mettre en œuvre le procédé d’envoi sécurisé d’un courrier électronique.
De plus, l’invention vient à améliorer la situation en proposant un appareil de confiance permettant l’envoi sécurisé d’un courrier électronique, l’appareil de confiance étant configuré pour mettre en œuvre le procédé d’envoi sécurisé d’un courrier électronique.
De plus, l’invention vient à améliorer la situation en proposant un procédé de réception sécurisée d’un courrier électronique par un utilisateur, le procédé comprenant : recevoir au niveau d’un serveur de messagerie électronique une requête pour recevoir le courrier électronique, l’utilisateur ayant un compte de messagerie électronique sur le serveur de messagerie électronique, l’utilisateur s’étant préalablement identifié au compte de messagerie électronique ; en réponse à la réception de la requête, envoyer par le serveur un test de sécurité à compléter par l’utilisateur à un appareil de confiance associé à l’utilisateur via un canal sécurisé ; recevoir le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé ; vérifier le test de sécurité complété par l’utilisateur par le serveur ; recevoir le courrier électronique par le serveur ; et envoyer le courrier électronique par le serveur à l’utilisateur si le test est validé par l’utilisateur.
Procédé de réception sécurisée d’un courrier électronique par un utilisateur, le procédé comprenant : recevoir, à un appareil de confiance associé à l’utilisateur, en réponse à la réception d’une requête de réception d’un courrier électronique par un serveur, un test de sécurité à compléter par l’utilisateur via un canal sécurisé ; et compléter le test de sécurité par l’utilisateur sur l’appareil de confiance ; transmettre le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé pour validation et transmission du courrier à l’utilisateur par le serveur si le test est validé par l’utilisateur.
D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement :
une représentation schématique d’un exemple de système permettant l’envoi sécurisé d’un courrier électronique ;
un exemple de procédé d’envoi sécurisé d’un courrier électronique ;
un exemple de procédé d’envoi sécurisé d’un courrier électronique ;
représente un exemple de procédé de réception sécurisée d’un courrier électronique ; et
représente un exemple de procédé de réception sécurisée d’un courrier électronique.
DESCRIPTION DETAILLEE
La illustre un exemple de système 100 permettant l’envoi sécurisé d’un courrier électronique.
Le système 100 comprend un serveur de messagerie électronique 102. Un utilisateur a un compte de messagerie électronique sur le serveur 102. L’utilisateur s’est préalablement identifié au compte de messagerie électronique. Le serveur peut être, par exemple, sur un réseau local de l’utilisateur. Le serveur 102 étant configuré pour recevoir une requête provenant de l’utilisateur pour envoyer le courrier électronique. Par exemple, le serveur de messagerie électronique 102 peut être un serveur 102 auquel l’utilisateur accède par un ordinateur personnel ou un ordinateur de travail, lui permettant d’accéder à une ou plusieurs boites aux lettres électroniques. Afin d’utiliser sa messagerie électronique liée au serveur 102, l’utilisateur s’est préalablement authentifié grâce à un nom d’utilisateur et un mot de passe. Lorsque l’utilisateur tente d’envoyer un courrier électronique qu’il/elle a rédigé depuis sa messagerie électronique, une requête pour envoyer le courrier électronique est transmise au serveur 102.
De plus, le système 100 comprend un appareil de confiance 104 associé à l’utilisateur, l’appareil de confiance 104 étant configuré pour recevoir un test de sécurité envoyé par le serveur à compléter par l’utilisateur et envoyer le test complété au serveur 102 via un canal sécurisé. Par exemple, l’appareil de confiance 104 peut être un téléphone portable, tel qu’un un smartphone, ou une tablette ou encore une montre intelligente associé à l’utilisateur. L’appareil de confiance 104 peut également être une clé USB ayant un dispositif permettant d’entrer une entrée biométrique.
Le test de sécurité peut comprendre une comparaison entre une entrée biométrique avec des données biométriques associées à l’utilisateur et stockées sur l’appareil de confiance 104 associé à l’utilisateur. Par exemple, l’appareil de confiance 104 peut comprendre un dispositif permettant de générer des données biométriques tel qu’un capteur d’empreintes digitales, de reconnaissance faciale, de balayage de l’iris ou d’analyse vocale. L’appareil de confiance 104 peut demander à l’utilisateur de rentrer ses données biométriques, par exemple son empreinte digitale en posant son doigt sur le capteur biométrique via son téléphone portable ou sa clé USB. Dans un autre exemple, les données biométriques peuvent être une reconnaissance faciale ou un signe de vie tel que le pouls ou la respiration de l’utilisateur. L’appareil de confiance 104 vérifie que l’empreinte digitale correspond à celle de l’utilisateur. Par exemple, l’appareil de confiance 104 peut stocker des données biométriques associées à un ou plusieurs utilisateurs préalablement entrées par l’utilisateur, afin de les comparer aux données biométriques générées lors du test de sécurité. L’appareil de confiance 104 peut émettre un résultat du test complété. Par exemple, si les données biométriques rentrées par l’utilisateur correspondent aux données stockées, l’appareil de confiance 104 peut émettre un résultat indiquant que les données sont celles de l’utilisateur. Au contraire, si les données biométriques rentrées par l’utilisateur ne correspondent pas aux données stockées, l’appareil de confiance 104 peut émettre un résultat indiquant que les données ne sont pas celles de l’utilisateur. Dans un exemple, l’appareil de confiance 104 peut déterminer que les biométriques rentrées par l’utilisateur correspondent aux données stockées lorsque que l’appareil de confiance 104 détermine que l’entrée biométrique satisfait un critère de similarité prédéfini par rapport aux données biométriques associées à l’utilisateur. Par exemple, le critère de similarité peut correspondre à un seuil de similarité entre l’entrée biométrique et les données biométriques associées à l’utilisateur. Dans un autre exemple, le test de sécurité peut comprendre un mot de passe. Par exemple, l’utilisateur peut recevoir une notification sur l’appareil de confiance 104 lui indiquant de rentrer un mot de passe. Le mot de passe peut être un de passe temporaire envoyé sur l’appareil de confiance 104, tel qu’un nombre envoyé sur le téléphone portable de l’utilisateur et utilisable pour quelques minutes. Dans un autre exemple, le mot de passe peut être un mot de passe permanent créé préalablement par l’utilisateur. Dans un autre exemple, le test peut être de répondre à une question dont la réponse a été préalablement enregistrée sur l’appareil de confiance 104 associé à l’utilisateur.
Dans un exemple, l’appareil de confiance 104 comprend une application permettant de compléter le test de sécurité. L’application peut être installée préalablement sur l’appareil de confiance 104. L’application peut par exemple stocker les données biométriques associées à l’utilisateur. Par exemple, l’application peut être associée avec une interface de programmation permettant à l’utilisateur d’enregistrer préalablement ses données biométriques.
Ainsi, lorsque que la requête pour envoyer le courrier électronique est transmise au serveur 102, le serveur 102 envoie le test de sécurité à compléter par l’utilisateur à l’appareil de confiance 104 associé à l’utilisateur via un canal sécurisé. Le canal sécurisé est un canal encrypté. Par exemple, le serveur 102 et l’appareil de confiance 104 peuvent communiquer en cryptant le test de sécurité l'un pour l'autre à l'aide d'une clé de session. De plus, dans un exemple, un algorithme de chiffrement par bloc (tel que SEED) peut être utilisé afin d’établir un cryptage du canal sécurisé. Par exemple, l’utilisateur peut recevoir une notification de l’application de l’appareil de confiance 104 lui indiquant qu’il/elle doit entrer ses données biométriques afin de compléter le test. L’utilisateur peut alors ouvrir l’application et compléter le test de sécurité, en entrant par exemple ses données biométriques. Une fois complété, le test de sécurité est renvoyé par l’appareil de confiance 104 au serveur 102 via le canal sécurisé. Par exemple, le résultat du test peut être envoyé par l’appareil de confiance 104 au serveur 102 via le canal sécurisé. Dans un exemple, le test de sécurité complété peut être crypté à l’aide d’une clé de session. Par exemple, l’appareil de confiance 104 peut générer aléatoirement la clé de session qui est cryptée avec une clé publique. Lorsque le serveur 102 reçoit le test de sécurité, le serveur 102 peut décrypter la clé de session à l’aide d’une clé privée.
Le serveur 102 peut ensuite valider le test de sécurité complété par l’utilisateur. Dans un exemple, l’appareil de confiance 104 peut envoyer au serveur 102 les données biométriques entrées par l’utilisateur et des données stockées sur l’appareil de confiance 104 représentant des données biométriques associées à l’utilisateur. Le serveur 102 peut ensuite comparer les données entrées et les données stockées et vérifier la correspondance entre les données. Dans un autre exemple, l’appareil de confiance 104 compare les données biométriques et des données stockées sur l’appareil de confiance 102 représentant des données biométriques associées à l’utilisateur et génère un résultat correspondant à un taux de correspondance entre les données entrées par l’utilisateur et les données stockées. Le taux de correspondance peut être ensuite envoyé au serveur 102. Le serveur 102 peut ensuite comparer le taux de correspondance avec un seuil. Dans un autre exemple, l’appareil de confiance 104 compare les données biométriques et des données stockées sur l’appareil de confiance 104 représentant des données biométriques associées à l’utilisateur et génère une indication booléenne (par exemple : « validé » ou « non validé »). L’appareil de confiance 104 envoie ensuite l’indication booléenne au serveur 102. Par exemple, lorsque le résultat du test reçu par le serveur 102 indique que les données sont celles de l’utilisateur, le serveur 102 envoie le courrier électronique. Au contraire, lorsque le résultat du test reçu par le serveur 102 indique que les données ne sont pas celles de l’utilisateur, le serveur n’envoie pas le courrier électronique (par exemple surprime le courrier électronique), ou alternativement le courrier électronique est renvoyé à l’utilisateur au lieu d’être envoyé au destinataire du courrier électronique. Dans un exemple, le serveur 102 peut émettre un message d’erreur.
De plus, le système 100 comprend une unité de destination 106 configurée pour recevoir l’email si le test de sécurité est validé par le serveur 102. Par exemple, l’unité de destination 106 peut être un ordinateur d’un autre utilisateur étant le destinateur du courrier électronique envoyé par l’utilisateur.
Le système 100 décrit ci-dessus permet d’utiliser une double authentification de l’utilisateur : l’authentification à l’aide d’un identifient et mot de passe pour accéder à la boite email et l’authentification au moment de l’envoie un courrier électronique avec l’utilisation d’un test de sécurité. Ainsi, le système 100 est avantageux car il permet de s’assurer que l’utilisateur envoie le courrier électronique lui-même et évitant ainsi le hameçonnage ou le piratage informatique.
La illustre un exemple de procédé 200a d’envoi sécurisé d’un courrier électronique. Le procédé 200a peut être implémenté par le serveur 102 décrit ci-dessus.
Au bloc 202a, le procédé 200a comprend recevoir au niveau d’un serveur 102 de messagerie électronique une requête provenant d’un utilisateur pour envoyer le courrier électronique, l’utilisateur ayant un compte de messagerie électronique sur le serveur 102 de messagerie électronique, l’utilisateur s’étant préalablement identifié au compte de messagerie électronique. L’utilisateur peut s’identifier en utilisant un nom d’utilisateur et un mot de passe. Par exemple, l’utilisateur rédige un courrier électronique qu’il/elle souhaite envoyer. Lorsque l’utilisateur souhaite envoyer le courrier électronique (par exemple en cliquant sur « envoyer »), une requête est envoyée au serveur 102. Il est noté qu’à ce stade, le courrier électronique n’est pas encore envoyé au destinataire. Le serveur 102 peut être sur un réseau local de l’utilisateur
Au bloc 204a, le procédé 200a comprend en réponse à la réception de la requête, envoyer par le serveur 102 un test de sécurité à compléter par l’utilisateur à un appareil de confiance 104 associé à l’utilisateur via un canal sécurisé. Dans un exemple, l’appareil de confiance 104 associé à l’utilisateur est un téléphone portable, comme par exemple un smartphone possédant un dispositif permettant de générer des données biométriques. Dans un autre exemple, l’appareil de confiance 104 est une tablette ou une montre intelligente. Dans un exemple, l’appareil de confiance 104 comprend une application permettant de compléter le test de sécurité. Par exemple, l’utilisateur reçoit une notification sur son téléphone portable pour entrer son empreinte digitale.
Au bloc 206a, le procédé 200a comprend recevoir le test de sécurité complété par l’utilisateur au serveur 102 via le canal sécurisé. Par exemple, le serveur 102 reçoit l’entrée biométrique entrée par l’utilisateur.
Au bloc 208a, le procédé 200a comprend vérifier le test de sécurité complété par l’utilisateur par le serveur 102. Par exemple, une comparaison entre l’entrée biométrique entrée par l’utilisateur avec des données biométriques associées à l’utilisateur. Par exemple, si l’entrée biométrique entrée par l’utilisateur correspond aux données biométriques associées à l’utilisateur, le test est validé. Au contraire, si l’entrée biométrique entrée par l’utilisateur ne correspond pas aux données biométriques associées à l’utilisateur, le test n’est pas validé.
Au bloc 210a, le procédé 200a comprend envoyer le courrier électronique par le serveur si le test est validé par l’utilisateur. En effet, si le test est validé, il est assuré que l’utilisateur qui envoie le courrier électronique est bien la personne associée à la boite email depuis laquelle le courrier électronique est envoyé.
Alternativement au bloc 201a, le procédé 200a peut comprendre rejeter le courrier électronique ou l’envoyer par le serveur à un autre destinataire que celui précisé dans le message si le test n’est pas validé par l’utilisateur. En effet, si le test n’est pas validé, cela signifie que l’utilisateur qui envoie le courrier électronique n’est pas la personne associée à la boite email depuis laquelle le courrier électronique est envoyé. Par exemple, le courrier électronique peut être est renvoyé à l’utilisateur qui a envoyé la requête au lieu d’être envoyé au destinataire du courrier électronique. Dans un exemple, un message d’erreur peut être envoyé à l’utilisateur.
Dans un exemple, le procédé 200a comprend des étapes supplémentaires comprenant : recevoir au niveau du serveur de messagerie électronique 102 une autre requête provenant de l’utilisateur pour envoyer un autre courrier électronique, vérifier un paramètre de sécurité prédéterminé et envoyer le courrier électronique par le serveur si le paramètre de sécurité prédéterminé est satisfait. Par exemple, le paramètre de sécurité peut comprendre un nombre de courriers électroniques, un temps écoulé entre la validation d’un dernier test de sécurité, un comportement suspect de l’utilisateur, et l’envoi d’une nouvelle requête, un changement d’adresse IP utilisée par l’utilisateur depuis la validation d’un dernier test de sécurité et une date à laquelle la requête est envoyée par l’utilisateur. Par exemple, l’utilisateur peut envoyer plusieurs courriers électroniques successivement ou simultanément. Si le nombre de courriers électroniques est en dessous d’un seuil prédéterminé, le serveur 102 envoie le courrier électronique. Au contraire, si le nombre de courriers électroniques dépasse du seuil prédéterminé, le serveur 102 n’envoie pas le courrier électronique. Dans un autre exemple, une requête correspondant à un comportement suspect peut être une requête pour envoyer un courrier électronique à l’intégralité d’un répertoire de contacts de l’utilisateur. Dans un autre exemple, un comportement suspect correspond à une présence de certains mots clé dans le courrier électronique, les mots clé étant préalablement définis. Dans ce cas, si le serveur 102 détecte un comportement suspect, le serveur 102 n’envoie pas le courrier électronique. Dans un autre exemple, lorsque que le serveur 102 détermine que l’adresse IP de l’utilisateur est la même pour plusieurs courriers électroniques envoyés successivement ou simultanément, le serveur 102 envoie le courrier électronique. Au contraire, si l’adresse IP a changé, le serveur 102 n’envoie pas le courrier électronique. Dans un exemple, des adresses IP peuvent être préalablement enregistrées comme étant des adresses IP de confiance. Par exemple, un utilisateur peut avoir des adresses IP de confiance correspondant à son domicile et son lieu de travail. Lorsque le serveur détecte que la requête a été envoyée avec une adresse IP de confiance, le serveur 102 envoie le courrier électronique. De plus ou alternativement, lorsque le serveur 102 détermine qu’un temps inférieur à un seuil de temps est écoulé entre la validation d’un dernier test de sécurité et l’envoi d’une nouvelle requête, le serveur 102 envoie le courrier électronique. Au contraire, lorsque le serveur 102 détermine qu’un temps supérieur à un seuil de temps est écoulé entre la validation d’un dernier test de sécurité et l’envoi d’une nouvelle requête, le serveur 102 n’envoie pas le courrier électronique. Ainsi, il est possible de faciliter l’envoi de courriers électroniques dans certaines situations qui ne sont pas considérées à risque. Par exemple, si l’adresse IP est inchangée, il peut être supposé que l’utilisateur est également inchangé. De plus, en définissant un temps écoulé entre deux requêtes, cela permet à l’utilisateur d’envoyer successivement plusieurs emails sans avoir besoin de compléter un test de sécurité plusieurs fois dans une courte durée. Au contraire, si une situation est considérée à risque, il est préférable de vérifier que l’utilisateur est bien l’utilisateur associée à la boite email depuis laquelle le courrier électronique est envoyé.
Il est noté que les étapes décrites ci-dessus aux blocs 202a-210a peuvent être effectuée au moment où le client de messagerie envoie par STPM le courrier électronique au serveur 102. En effet, due à l’ancienneté de la technologie et des protocoles utilisés dans l’envoi des courriers électroniques, il y a un délai entre le moment où l’utilisateur clique sur « envoyer » et le moment où le destinataire reçoit le courrier électronique. Ainsi, il est possible de profiter de ce délai pour compléter ces étapes en évitant un délai supplémentaire.
La illustre un exemple de procédé 200b d’envoi sécurisé d’un courrier électronique. Le procédé 200b peut être implémenté par l’appareil de confiance 104 décrit ci-dessus.
Au bloc 202b, le procédé 200b comprend recevoir, à un appareil de confiance 104 associé à l’utilisateur en réponse à la réception d’une requête de transmission d’un courrier électronique par un serveur, un test de sécurité à compléter par l’utilisateur via un canal sécurisé. Par exemple, lorsque le serveur 102 reçoit la requête provenant de l’utilisateur pour envoyer le courrier électronique dans l’exemple du procédé 200a décrit ci-dessus, le serveur 102 envoie un test de sécurité à l’appareil de confiance 104 pour qu’il soit complété par l’utilisateur. Le test à compléter peut être par exemple une notification pour entrer des données biométriques.
Au bloc 204b, le procédé 200b comprend compléter comprend test de sécurité par l’utilisateur sur l’appareil de confiance 104. Par exemple, suite à la réception d’une notification sur son téléphone portable 104 pour entrer son empreinte digitale, l’utilisateur entre son empreinte digitale à l’aide du dispositif permettant de générer des données biométriques présent sur son téléphone portable 104.
Au bloc 206b, le procédé 200b comprend transmettre le test de sécurité complété par l’utilisateur au serveur 102 via le canal sécurisé pour validation et transmission du courrier électronique par le serveur 102 si le test est validé par l’utilisateur. Par exemple, si le test de sécurité complété par l’utilisateur consiste à rentrer des données biométriques, l’appareil de confiance 104 transmet les données obtenues au serveur, ou encore la comparaison entre les données biométriques entrées par l’utilisateur avec des données stockées sur l’appareil de confiance 104 associées à l’utilisateur ou encore un résultat du test (par exemple « validé » ou « non validé »).
Les procédés 200a, 200b décrits ci-dessus permettent ainsi de s’assurer que l’utilisateur qui envoie le courrier électronique est bien la personne associée à la boite email depuis laquelle le courrier électronique est envoyé. Ainsi, les procédés 200a, 200b permettent d’éviter le hameçonnage et le piratage informatique de boite email.
La illustre un exemple de procédé 300a de réception sécurisée d’un courrier électronique par un utilisateur. Le procédé 300a peut être implémenté par le serveur 102 décrit ci-dessus. En effet, le serveur 102 peut être utilisé pour la transmission et la réception de courriers électroniques.
Au bloc 302a, le procédé 300a comprend recevoir au niveau d’un serveur de messagerie électronique une requête pour recevoir le courrier électronique, l’utilisateur ayant un compte de messagerie électronique sur le serveur de messagerie électronique, l’utilisateur s’étant préalablement identifié au compte de messagerie électronique. Par exemple, un expéditeur veut envoyer un courrier électronique à l’utilisateur. Cependant, par exemple en cas de confidentialité, il est important que ce courrier électronique soit reçu par le bon utilisateur.
Au bloc 304a, le procédé 300a comprend en réponse à la réception de la requête, envoyer par le serveur 102 un test de sécurité à compléter par l’utilisateur à un appareil de confiance 104 associé à l’utilisateur via un canal sécurisé. Par exemple, l’utilisateur reçoit une notification sur son téléphone pour compléter un test de sécurité, tel que l’entrée de données biométriques.
Au bloc 306a, le procédé 300a comprend recevoir le test de sécurité complété par l’utilisateur au serveur 102 via le canal sécurisé. Par exemple, le serveur 102 reçoit les données biométriques entrées par l’utilisateur.
Au bloc 308a, le procédé 300a comprend vérifier le test de sécurité complété par l’utilisateur par le serveur. Par exemple, reçoit les données biométriques entrées par l’utilisateur sont comparées avec des données biométriques associées à l’utilisateur. Si les données sont similaires, le test est validé et l’utilisateur correspond au destinataire du courrier électronique. Au contraire, si les données sont différentes, le test n’est pas validé et l’utilisateur ne correspond pas au destinataire du courrier électronique.
Au bloc 310a, le procédé 300a comprend recevoir le courrier électronique par le serveur.
Au bloc 312a, le procédé 300a comprend envoyer le courrier électronique par le serveur à l’utilisateur si le test est validé par l’utilisateur. L’utilisateur peut donc ouvrir le courrier électronique. Au contraire, si le test n’est pas validé, le serveur 102 n’envoie pas l’email au destinataire et rejette le message. Par exemple, un message d’erreur s’affiche sur l’écran de l’ordinateur de l’utilisateur.
La illustre un exemple de procédé 300b de réception sécurisée d’un courrier électronique par un utilisateur. Le procédé 300b peut être implémenté par l’appareil de confiance 104 décrit ci-dessus. En effet, l’appareil de confiance 104 peut être utilisé pour la transmission et la réception de courriers électroniques.
Au bloc 302b, le procédé 300b comprend recevoir, à un appareil de confiance 104 associé à l’utilisateur, en réponse à la réception d’une requête de réception d’un courrier électronique par un serveur 102 un test de sécurité à compléter par l’utilisateur via un canal sécurisé. Par exemple, l’utilisateur reçoit une notification pour entrer ses données biométriques ou un mot de passe.
Au bloc 304b, le procédé 300b comprend compléter le test de sécurité par l’utilisateur sur l’appareil de confiance 104. Par exemple, l’utilisateur entre ses données biométriques sur son téléphone portable.
Au bloc 306b, le procédé 300b, le procédé 300b comprend transmettre le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé pour validation et transmission du courrier à l’utilisateur par le serveur si le test est validé par l’utilisateur. Par exemple, si le test de sécurité complété par l’utilisateur consiste à rentrer des données biométriques, l’appareil de confiance 104 transmet les données obtenues au serveur, ou encore la comparaison entre les données biométriques entrées par l’utilisateur avec des données stockées sur l’appareil de confiance 104 associées à l’utilisateur ou encore un résultat du test (par exemple « validé » ou « non validé »).
Il est noté que le procédés 300a, 300b peuvent être implémentés en combinaison avec le procédés 200a, 200b ou séparément. De plus, les procédés 300a, 300b peuvent être implémentés par le système 100 décrit ci-dessus. Tout comme pour les procédés 200a, 200b, il est également possible de définir un paramètre de sécurité dans le procédé 300. Par exemple, un temps écoulé entre deux requêtes pour recevoir un courrier électronique peut être défini afin d’éviter à l’utilisateur de compléter un test lorsque que plusieurs emails sont reçus dans une courte durée. En effet, le procédé 300a peut également comprendre recevoir au niveau du serveur de messagerie électronique 102 une autre requête provenant de l’utilisateur pour envoyer un autre courrier électronique, vérifier un paramètre de sécurité prédéterminé et envoyer le courrier électronique par le serveur si le paramètre de sécurité prédéterminé est satisfait. Par exemple, le paramètre de sécurité peut comprendre un nombre de courriers électroniques, un temps écoulé entre la validation d’un dernier test de sécurité, un comportement suspect de l’utilisateur, et l’envoi d’une nouvelle requête, un changement d’adresse IP utilisée par l’utilisateur depuis la validation d’un dernier test de sécurité et une date à laquelle la requête est envoyée par l’utilisateur.
Le procédé 300a permet ainsi de s’assurer que le courrier électronique est reçu par la personne à qui il est destiné. Par exemple, si plusieurs utilisateurs utilisent un même appareil (tel qu’un ordinateur), il peut être important de s’assurer que seul un des utilisateurs puisse accéder à sa boite email et à des courriers électroniques confidentiels par exemple. De plus, le procédé 300a permet de s’assurer que l’utilisateur ne reçoit pas des courriers indésirables.
Il doit être compris que les modes de réalisation de la présente invention peuvent être mis en œuvre par un produit-programme d’ordinateur comprenant des instructions et étant exécuté par un ordinateur. Par exemple, les procédés 200a, 200b, 300a, 300b peuvent être mis en œuvre en utilisant des dispositifs informatiques, un logiciel et/ou une combinaison de ceux-ci. Par exemple, les dispositifs informatiques peuvent être mis en œuvre à l'aide de circuits de traitement tels que, mais sans s'y limiter, un processeur, une unité centrale de traitement (CPU), un contrôleur, une unité arithmétique et logique (ALU), un processeur de signal numérique, un micro-ordinateur, un champ un réseau de portes programmable (FPGA), un système sur puce (SoC), une unité logique programmable, un microprocesseur ou tout autre dispositif capable de répondre et d'exécuter des instructions d'une manière définie. Le logiciel peut inclure un programme informatique, un code de programme, des instructions, ou une combinaison de ceux-ci, pour instruire ou configurer indépendamment ou collectivement un dispositif matériel pour qu'il fonctionne comme souhaité. Le programme informatique et/ou le code de programme peuvent comprendre des instructions de programme ou lisibles par ordinateur, des composants logiciels, des modules logiciels, des fichiers de données, des structures de données et/ou similaires, pouvant être mis en œuvre par un ou plusieurs dispositifs matériels, tels qu'un ou plus des périphériques matériels mentionnés ci-dessus. Lorsqu'un dispositif matériel est un dispositif de traitement informatique (par exemple, CPU, un contrôleur, une ALU, un processeur de signal numérique, un micro-ordinateur, un microprocesseur, etc.), le dispositif de traitement informatique peut être configuré pour exécuter un code de programme en effectuant des opérations arithmétiques, opérations logiques et d'entrée/sortie, selon le code du programme. L’unité de contrôle 106 peut également comprendre un ou plusieurs dispositifs de stockage. Le ou les dispositifs de stockage peuvent être des supports de stockage lisibles par ordinateur tangibles ou non transitoires, tels qu'une mémoire vive (RAM), une mémoire morte (ROM), un dispositif de stockage de masse permanent (tel qu'un lecteur de disque), un (par exemple, flash NAND) et/ou tout autre mécanisme de stockage de données similaire capable de stocker et d'enregistrer des données. Le ou les dispositifs de stockage peuvent être configurés pour stocker des programmes informatiques, un code de programme, des instructions ou une combinaison de ceux-ci, pour un ou plusieurs systèmes d'exploitation et/ou pour mettre en œuvre les exemples de modes de réalisation décrits ici. Les programmes informatiques, le code de programme, les instructions ou une combinaison de ceux-ci peuvent également être chargés à partir d'un support de stockage lisible par ordinateur séparé dans le ou les dispositifs de stockage et/ou un ou plusieurs dispositifs de traitement informatique à l'aide d'un mécanisme d'entraînement. Un tel support de stockage lisible par ordinateur séparé peut comprendre une clé USB (Universal Serial Bus), une clé mémoire, un lecteur Blu-ray/DVD/CD-ROM, une carte mémoire et/ou d'autres supports de stockage lisibles par ordinateur.
Bien que l'invention ait été illustrée et décrite en détail à l'aide de modes de réalisations préférés, l'invention n'est pas limitée aux exemples divulgués. D'autres variantes peuvent être déduites par l'homme du métier sans sortir du cadre de protection de l'invention revendiquée. Par exemple, bien que les procédés 200a, 200b et les procédés 300a, 300b aient été décrits séparément, ils peuvent être utilisés par un même système. De plus, bien que l’ordinateur sur lequel l’utilisateur rédige son courrier électronique et l’appareil de confiance aient été décrits comme étant deux dispositifs différents, ils peuvent être un même dispositif.

Claims (13)

  1. Procédé d’envoi sécurisé d’un courrier électronique, le procédé comprenant :
    - recevoir au niveau d’un serveur de messagerie électronique une requête provenant d’un utilisateur pour envoyer le courrier électronique, l’utilisateur ayant un compte de messagerie électronique sur le serveur de messagerie électronique, l’utilisateur s’étant préalablement identifié au compte de messagerie électronique ;
    - en réponse à la réception de la requête, envoyer par le serveur un test de sécurité à compléter par l’utilisateur à un appareil de confiance associé à l’utilisateur via un canal sécurisé ;
    - recevoir le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé ;
    - vérifier le test de sécurité complété par l’utilisateur par le serveur ; et
    - envoyer le courrier électronique par le serveur si le test est validé par l’utilisateur.
  2. Procédé d’envoi sécurisé d’un courrier électronique, le procédé comprenant :
    - recevoir, à un appareil de confiance associé à l’utilisateur en réponse à la réception d’une requête de transmission d’un courrier électronique par un serveur, un test de sécurité à compléter par l’utilisateur via un canal sécurisé ;
    - compléter le test de sécurité par l’utilisateur sur l’appareil de confiance ;
    - transmettre le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé pour validation et transmission du courrier électronique par le serveur si le test est validé par l’utilisateur.
  3. Procédé de détection d’une requête pour l’envoi d’un courrier électronique, le procédé comprenant :
    - recevoir au niveau d’un serveur de messagerie électronique une requête provenant d’un utilisateur pour envoyer le courrier électronique, l’utilisateur ayant un compte de messagerie électronique sur le serveur de messagerie électronique, l’utilisateur s’étant préalablement identifié au compte de messagerie électronique ;
    - en réponse à la réception de la requête, envoyer par le serveur un test de sécurité à compléter par l’utilisateur à un appareil de confiance associé à l’utilisateur via un canal sécurisé ;
    - recevoir le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé ;
    - vérifier le test de sécurité complété par l’utilisateur par le serveur ; et
    - rejeter le courrier électronique ou l’envoyer par le serveur à un autre destinataire que celui précisé dans le message si le test n’est pas validé par l’utilisateur.
  4. Procédé d’envoi sécurisé d’un courrier électronique selon la revendication 1, dans lequel le procédé comprend en outre :
    - recevoir au niveau du serveur de messagerie électronique une autre requête provenant de l’utilisateur pour envoyer un autre courrier électronique ;
    - vérifier un paramètre de sécurité prédéterminé ;
    - envoyer le courrier électronique par le serveur si le paramètre de sécurité prédéterminé est satisfait.
  5. Procédé d’envoi sécurisé d’un courrier électronique selon la revendication 4, le paramètre de sécurité comprenant : un temps écoulé entre l’envoie de la requête et de l’autre requête, un changement d’adresse IP utilisée par l’utilisateur et une date à laquelle la requête est envoyée par l’utilisateur.
  6. Procédé d’envoi sécurisé d’un courrier électronique selon l’une des revendications précédentes, dans lequel le test de sécurité comprend une comparaison d’une entrée biométrique avec des données biométriques associées à l’utilisateur et stockées sur l’appareil de confiance associé à l’utilisateur.
  7. Procédé d’envoi sécurisé d’un courrier électronique selon l’une des revendications précédentes, dans lequel l’appareil de confiance associé à l’utilisateur est un téléphone portable ou une clé USB.
  8. Procédé d’envoi sécurisé d’un courrier électronique selon l’une des revendications précédentes, dans lequel l’appareil de confiance comprend une application permettant de compléter le test de sécurité.
  9. Produit-programme d’ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, amènent l'ordinateur à mettre en œuvre le procédé de l'une quelconque des revendications précédentes.
  10. Un serveur permettant l’envoi sécurisé d’un courrier électronique, le serveur étant configuré pour mettre en œuvre le procédé de la revendication 1.
  11. Un appareil de confiance permettant l’envoi sécurisé d’un courrier électronique, l’appareil de confiance étant configuré pour mettre en œuvre le procédé de la revendication 2.
  12. Procédé de réception sécurisée d’un courrier électronique par un utilisateur, le procédé comprenant :
    - recevoir au niveau d’un serveur de messagerie électronique une requête pour recevoir le courrier électronique, l’utilisateur ayant un compte de messagerie électronique sur le serveur de messagerie électronique, l’utilisateur s’étant préalablement identifié au compte de messagerie électronique ;
    - en réponse à la réception de la requête, envoyer par le serveur un test de sécurité à compléter par l’utilisateur à un appareil de confiance associé à l’utilisateur via un canal sécurisé ;
    - recevoir le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé ;
    - vérifier le test de sécurité complété par l’utilisateur par le serveur ;
    - recevoir le courrier électronique par le serveur ; et
    - envoyer le courrier électronique par le serveur à l’utilisateur si le test est validé par l’utilisateur.
  13. Procédé de réception sécurisée d’un courrier électronique par un utilisateur, le procédé comprenant :
    - recevoir, à un appareil de confiance associé à l’utilisateur, en réponse à la réception d’une requête de réception d’un courrier électronique par un serveur, un test de sécurité à compléter par l’utilisateur via un canal sécurisé ; et
    - compléter le test de sécurité par l’utilisateur sur l’appareil de confiance ;
    - transmettre le test de sécurité complété par l’utilisateur au serveur via le canal sécurisé pour validation et transmission du courrier à l’utilisateur par le serveur si le test est validé par l’utilisateur.
FR2204976A 2022-05-24 2022-05-24 Procédé d’envoi sécurisé d’un courrier électronique Active FR3136073B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR2204976A FR3136073B1 (fr) 2022-05-24 2022-05-24 Procédé d’envoi sécurisé d’un courrier électronique
US18/316,950 US20230388300A1 (en) 2022-05-24 2023-05-12 Method for securely sending an email
US19/279,907 US20250358281A1 (en) 2022-05-24 2025-07-24 Method for securely sending an email

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2204976 2022-05-24
FR2204976A FR3136073B1 (fr) 2022-05-24 2022-05-24 Procédé d’envoi sécurisé d’un courrier électronique

Publications (2)

Publication Number Publication Date
FR3136073A1 true FR3136073A1 (fr) 2023-12-01
FR3136073B1 FR3136073B1 (fr) 2024-10-04

Family

ID=83438341

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2204976A Active FR3136073B1 (fr) 2022-05-24 2022-05-24 Procédé d’envoi sécurisé d’un courrier électronique

Country Status (2)

Country Link
US (2) US20230388300A1 (fr)
FR (1) FR3136073B1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200336451A1 (en) * 2016-01-26 2020-10-22 ZapFraud, Inc. Detecting of business email compromise
US20210184851A1 (en) * 2019-10-31 2021-06-17 Mastercard International Incorporated Authentication device, system and method
CN109039860B (zh) * 2018-07-17 2021-07-30 北京小米移动软件有限公司 发送和展示消息的方法及装置、身份认证的方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7117370B2 (en) * 2001-02-20 2006-10-03 Sal Khan System for transmitting secure data between a sender and a recipient over a computer network using a virtual envelope and method for using the same
JP2007140864A (ja) * 2005-11-17 2007-06-07 Fujitsu Ltd データ転送装置、データ転送方法、データ転送プログラム、通信端末装置及びデータ転送システム
JP2010020712A (ja) * 2008-07-14 2010-01-28 Canon Inc 情報処理装置、情報処理装置の制御方法、記憶媒体及びプログラム
US11843597B2 (en) * 2016-05-18 2023-12-12 Vercrio, Inc. Automated scalable identity-proofing and authentication process
US10902148B2 (en) * 2017-12-07 2021-01-26 Verizon Media Inc. Securing digital content using separately authenticated hidden folders
NL2026156B1 (en) * 2020-07-24 2022-04-12 Anthony Francis Everts Roy A method that adequately protects the authentic identity and personal data of a natural person and remotely confirms the authentic identity of this natural person through a trusted entity to a beneficiary party.
US11550964B2 (en) * 2021-01-21 2023-01-10 Vmware, Inc. Account-specific security in an email client

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200336451A1 (en) * 2016-01-26 2020-10-22 ZapFraud, Inc. Detecting of business email compromise
CN109039860B (zh) * 2018-07-17 2021-07-30 北京小米移动软件有限公司 发送和展示消息的方法及装置、身份认证的方法及装置
US20210184851A1 (en) * 2019-10-31 2021-06-17 Mastercard International Incorporated Authentication device, system and method

Also Published As

Publication number Publication date
US20230388300A1 (en) 2023-11-30
US20250358281A1 (en) 2025-11-20
FR3136073B1 (fr) 2024-10-04

Similar Documents

Publication Publication Date Title
CN102067103B (zh) 改进的经证明的电子邮件消息及附件
US9092599B1 (en) Managing knowledge-based authentication systems
EP3568965B1 (fr) Procédé d'authentification en deux étapes, dispositif et programme d'ordinateur correspondant
EP3022867A1 (fr) Procéde d'authentification forte
WO2010151873A1 (fr) Systèmes et procédés de messagerie électronique sécurisée et certifiée
US20250252164A1 (en) Multidimensional local large language model user authentication
EP2568406B1 (fr) Procédé de mise en oeuvre, a partir d'un terminal, de données cryptographiques d'un utilisateur stockées dans une base de données
WO2003107587A1 (fr) Procede et dispositif d’interface pour echanger de maniere protegee des donnees de contenu en ligne
FR3002670A1 (fr) Procede et systeme de traitement cryptographique utilisant une donnee sensible
WO2023057652A1 (fr) Application de sécurité pour un dispositif informatique, et architecture de sécurité correspondante
FR3136073A1 (fr) Procédé d’envoi sécurisé d’un courrier électronique
EP3673633B1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
FR3047622B1 (fr) Procede de controle d'un parametre indicatif d'un niveau de confiance associe a un compte utilisateur d'un service en ligne
EP3594880A1 (fr) Procédé de transmission sécurisée de données cryptographiques
FR3133250A1 (fr) Procédé d’accès sécurisé à des données numériques
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
CN105635119A (zh) 一种传播内容的防伪方法和装置
EP4661341A1 (fr) Procédé d'authentification d'un terminal pour travailleur isolé auprès d'un serveur distant
FR3134908A1 (fr) Procédé et système de gestion des droits d’accès dans une transaction équitable de données numériques
WO2025125562A1 (fr) Procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile
FR2990818A1 (fr) Procede de transfert et de stockage securise de documents et appareils associes au procede.
EP3394780A1 (fr) Procede et dispositif de connexion a un serveur distant
FR3026875A1 (fr) Procedes de configuration d'un peripherique de type terminal connecte a un reseau afin de permettre une authentification forte d'un utilisateur
FR2888437A1 (fr) Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20231201

PLFP Fee payment

Year of fee payment: 3

RM Correction of a material error

Effective date: 20250117

PLFP Fee payment

Year of fee payment: 4