PT739560E - Sistema criptografico e processo com caracteristica de garantia de chave - Google Patents

Sistema criptografico e processo com caracteristica de garantia de chave Download PDF

Info

Publication number
PT739560E
PT739560E PT95908511T PT95908511T PT739560E PT 739560 E PT739560 E PT 739560E PT 95908511 T PT95908511 T PT 95908511T PT 95908511 T PT95908511 T PT 95908511T PT 739560 E PT739560 E PT 739560E
Authority
PT
Portugal
Prior art keywords
key
user
certificate
message
public
Prior art date
Application number
PT95908511T
Other languages
English (en)
Inventor
Frank W Sudia
Original Assignee
Certco Inc
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 Certco Inc filed Critical Certco Inc
Publication of PT739560E publication Critical patent/PT739560E/pt

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F7/60—Methods or arrangements for performing computations using a digital non-denominational number representation, i.e. number representation without radix; Computing devices using combinations of denominational and non-denominational quantity representations, e.g. using difunction pulse trains, STEELE computers, phase computers
    • G06F7/72—Methods or arrangements for performing computations using a digital non-denominational number representation, i.e. number representation without radix; Computing devices using combinations of denominational and non-denominational quantity representations, e.g. using difunction pulse trains, STEELE computers, phase computers using residue arithmetic
    • G06F7/724—Finite field arithmetic
    • G06F7/725—Finite field arithmetic over elliptic curves

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Sub-Exchange Stations And Push- Button Telephones (AREA)

Description

86 259 ΕΡ Ο 739 560/ΡΤ
DESCR1CÃO “Sistema criptográfico e processo com característica de garantia de chave”
Antecedentes do invento
Este invento refere-se a sistemas de comunicações criptográficas. Mais particularmente, este invento refere-se à geração, certificação, armazenagem e distribuição segura de chaves criptográficas, utilizadas em sistemas de comunicações criptográficas. Ainda mais particularmente, este invento refere-se a um sistema de garantia de chaves criptográficas e de administração de certificados de chave pública postos em vigor por um dispositivo de pastilha com certificação própria. O desenvolvimento e a proliferação de tecnologia de computadores sofisticada e de sistemas de processamento de dados distribuídos levou a um rápido aumento da transferência de informação na forma digital. Esta informação é utilizada em assuntos da banca e financeiros, em correio electrónico, na troca de dados electrónicos e outros sistemas de processamento de dados. A transmissão desta informação em canais de comunicação não protegidos ou não seguros corre o risca de exposição da informação transmitida a uma escuta clandestina ou a uma alteração. Os sistemas de comunicações criptográficas conservam a privacidade destas transmissões evitando a monitorização por partes não autorizadas de mensagens transmitidas num canal não seguro. Os sistemas de comunicações criptográficas podem assegurar ainda a integridade e autenticidade da transmissão através do fornecimento para reconhecimento, de assinaturas digitalizadas, dependentes do documento e não olvidáveis, que podem evitar a negação pelo remetente da sua própria mensagem.
Os sistemas criptográficos envolvem a codificação ou cifração de transmissões de dados digitais, incluindo voz diyilalizada ou transmissões de vídeo, para as tornar incompreensíveis por todos que não o receptor desejado. Uma mensagem em texto claro, que consiste em sons digitalizados, letras e/ou números, é codificada numericamente e então cifrada utilizando um algoritmo matemático complexo que transforma a mensagem codificada apoiada num dado conjunto de números ou dígitos, também conhecido como uma chave de cifra. A chave de cifra é uma sequência de bits de dados, que pode ou ser escolhida aleatoriamente ou ter propriedades matemáticas especiais, dependendo do algoritmo ou sistema de cifra
86 259 ΕΡ Ο 739 560/ΡΤ utilizados. Os algoritmos criptográficos sofisticados implementados em computadores podem transformar e manipular números que têm centenas ou milhares de bits de comprimento e podem resistir a qualquer processo conhecido de descodificação não autorizada. Existem duas classes básicas de algoritmos criptográficos: algoritmos de chave simétrica e algoritmos de chave assimétrica.
Os algoritmos de chave simétrica utilizam uma chave de cifra idêntica para tanto para cifração pelo remetente da comunicação como para decifração pelo receptor da comunicação. Os sistemas de cifra de chave simétrica são construídos na confiança mútua das duas partes, que repartem a chave de cifra para utilizar o sistema de cifra para o proteger contra terceiras partes não confiáveis. O algoritmo de chave simétrica melhor conhecido é o algoritmo Padrão de Cifração de Dados Nacional (DES) publicado primeiro pelo National Institute of Standards and Technology. Ver o Federal Reqister. 17 de Março de 1975, Vol. 40, n°. 52 e 1 de Agosto de 1975, Vol. 40, n°. 149. O dispositivo criptográfico remetente utiliza o algoritmo DES para cifrar a mensagem, quando carregada com a chave de cifra (uma chave de cifra DES tem o comprimento de 56 bits) para a sessão de comunicação (a chave de sessão). O dispositivo criptográfico receptor utiliza um inverso do algoritmo DES para decifrar a mensagem cifrada, quando carregada com a mesma chave de cifra que foi utilizada para a cifração. No entanto, a adequação de sistemas de cifra de chave simétrica em geral foram questionados em virtude da necessidade do remetente e do receptor trocarem a chave de cifra através de um canal seguro, ao qual nenhuma terceira parte não autorizada tenha acesso, antes das comunicações desejadas entre o remetente e o receptor. Este processo de trocar com segurança chaves de cifra, em primeiro lugar, e apenas depois cifrar a comunicação é muita vezes vagaroso e incómodo, e é portanto inviável em situações que exigem comunicações espontâneas ou não solicitadas, ou em situações que exigem comunicações entre partes não familiarizadas entre si. Além disso, a intercepção da chave de cifra por uma terceira parte não autorizada possibilitará à parte escutar clandestinamente nas duas pontas da conversação cifrada. A segunda classe de algoritmos criptográficos, algoritmos de chave assimétrica, utiliza chaves de cifra diferentes, para cifrar e decifrar. Num sistema de cifra utilizando um algoritmo de chave assimétrica, o utilizador torna a chave de cifração pública e mantém a chave de decifração privada, e não é possível obter a chave de decifração privada a partir da chave de cifração pública. Assim, qualquer pessoa que conheça a chave pública de um utilizador particular pode codificar uma
86 259 ΕΡ Ο 739 560/ΡΤ mensagem para ο utilizador, visto que apenas o utilizador que é o dono da chave privada que corresponde à chave pública pode decifrar a mensagem. Este sistema de chave pública/privada foi primeiro proposto no Diffie and Hellman, “New Directions in Cryptography” IEEE Transactions on Information Theory, de Novembro de 1976, e na patente US n°. 4.200.770 (Hellman et al).
Um tipo anterior de algoritmos de chave assimétrica permite comunicações seguras através de um canal inseguro pela criação interactiva, pelas partes que comunicam entre si, de uma chave de cifra para a sessão de comunicação. Utilizando o algoritmo de chave assimétrica, dois utilizadores interagindo simultaneamente e independentemente geram uma chave de cifra segura, que não pode ser desenvolvida por quem escuta clandestinamente, e que é para ser utilizada simetricamente para codificar a sessão de comunicações entre os utilizadores. Este processo interactivo de gerar uma chave de cifra segura foi descrito por Diffie e Hellman no seu escrito de 1976. Neste processo da técnica anterior, conhecido como o esquema Interactive Diffie-Hellman, mostrado na Fig. 2, cada um dos dois utilizadores A, B escolhem aleatoriamente um número secreto 21, 22 e depois calculam um número intermédio 23, 24, utilizando dois números conhecidos publicamente e o número secreto 21, 22 escolhidos pelo utilizador. Cada utilizador transmite em seguida o número intermédio 23, 24 para o outro utilizador e calculam então a chave de cifra secreta (simétrica) 25, utilizando o seu próprio número secreto 21, 22 e o número intermédio 24, 23 acabados de receber do outro utilizador. A chave de cifra 25 gerada interactivamente é então utilizada simetricamente por ambos os utilizadores como uma chave de cifra simétrica DES ou outra para cifrar e decifrar a sessão de comunicações sobre um canal de outro modo inseguro do modo das comunicações de algoritmo de chave simétrica. Este processo interactivo exige apenas uns poucos segundos de tempo real, e todos as comunicações digitais, incluindo transmissões de som ou vídeo digitalizadas, numa sessão particular podem ser cifradas simplesmente através de premir um botão no principio de uma sessão para iniciar o processo de troca de chave interactiva. Em virtude de todos os números escolhidos no esquema de geração de chave Interactive Diffie-Hellman serem muito grandes, os cálculos são impossíveis para inverter e a chave de cifra secreta não pode ser calculada por quem escuta clandestinamente, preservando assim a privacidade da comunicação. Em virtude dos cálculos serem impossíveis para inverter, cada utilizador sabe que qualquer comunicação recebida utilizando este algoritmo não foi alterada e pode ter sido enviada apenas pelo outro utilizador, preservando assim a integridade e autenticidade da comunicação. Este processo de troca de chave interactiva, exige,
86 259 ΕΡ Ο 739 560/ΡΤ 4 no entanto, que as partes interajam em tempo real a fim de criar a chave de cifra e pode não ser útil para comunicações não solicitadas ou partes não familiarizadas. Em particular, o esquema de troca de chave Interactive Diffie-Hellman não funciona para correio electrónico armazenado e transmitido estilo mensagem ou para armazenagem a longo termo de documentos num sistema de armazenagem de dados electrónicos, em virtude do receptor não estar em tempo real para negociar a chave de sessão.
Uma forma não interactiva modificada do esquema Diffie-Hellman, conhecida como Certified Diffie-Hellman, pode ser utilizada, quando as partes que comunicam não estão juntos em tempo real. O passo de certificação inicial do esquema de geração de chave de sessão Certified Diffie-Hellman é mostrado na Fig. 3. Um utilizador, a ser o receptor, escolhe aleatoriamente um número secreto 31 (a sua chave privada) e calcula então um número intermédio 33 utilizando os dois números conhecidos publicamente 32 e o número secreto 31 escolhido pelo utilizador. O utilizador envia então a prova de identificação ao mesmo tempo que o número intermédio e os dois números públicos, os quais números juntos formam a sua chave pública 34, para uma autoridade de certificação que emite então um certificado de chave pública 35 assinado digitalmente 36, pela autoridade de certificação emissora, que faz a ligação da identidade do utilizador à informação de chave pública Diffie-Hellman 34 do utilizador. A chave pública 34 publicitada pelo utilizador permanece a mesma até que ele decida mudar de chave e escolher outra chave privada 31. As mensagens utilizando o processo Certified Diffie-Hellman são mostradas na Fig. 4. A fim de transmitir uma mensagem para o utilizador, um utilizador remetente obtém primeiro o certificado 35 do utilizador de recepção e verifica a assinatura 36 da autoridade de certificação. O remetente calcula então a chave de sessão 42 para a sessão de comunicação utilizando o número intermédio 33 do receptor (a partir do certificado do receptor) e o próprio número secreto 41 do remetente (a sua chave privada), a qual ele escolhe aleatoriamente. O remetente cifra então uma mensagem 43, utilizando a chave de sessão 42 e coloca o seu próprio número intermédio 40 decifrado no cabeçalho da comunicação. Durante a recepção da comunicação, o receptor calcula a chave de sessão 42 utilizando o número intermédio decifrado 40 do remetente e o seu próprio número secreto 31 (ou chave privada), e utiliza então a chave de sessão 42 para decifrar a mensagem 43. Como com o esquema Interactive Diffie-Hellman, a chave de sessão gerada no esquema Certified Diffie-Hellman é então utilizada por ambas as partes para cifrar e decifrar as comunicações durante a sessão através de um canal inseguro, de outro modo utilizando um algoritmo simétrico convencional, tal como o DES. O esquema 86 259 ΕΡ Ο 739 560/ΡΤ 5
Certified Diffie-Hellman exige, no entanto, que uma entidade de confiança oú uma autoridade certificada assine o certificado de chave pública do utilizador recebido, a fim de que um utilizador remetente possa confiar que a informação contida dentro do mesmo está correcta. Adicionalmente, a chave privada escolhida aleatoriamente pelo remetente, com a qual ele calcula ambas a chave de sessão e o número intermédio para a comunicação, não deve ser idêntica à chave privada, a qual é ligada ao certificado de chave pública do próprio remetente, a fim de evitar que outros fiquem a conhecer os seus números de chave privada permanente (correspondendo aos números de chave pública que foram certificados, o remetente deveria conservá-los distintos de quaisquer chaves privadas efémeras ou números intermédios que são gerados apenas para mensagens específicas.
Outro algoritmo de chave assimétrica, chamado o algoritmo RSA dos inventores Rivest, Shamir e Adleman, é descrito na patente U.S. n°. 4.405.829 (Rivest et al.), e envolve a dificuldade dividir em factores um número que é o produto de dois primos números grandes. Como com o esquema Interactive Diffie-Hellman, o algoritmo RSA é relativamente directo de calcular mas praticamente impossível de ser invertido. Assim, não é possível originar a chave privada a partir da chave pública e, desta maneira, a privacidade da comunicação é preservada. Logo que uma mensagem é cifrada com a chave pública, utilizando o algoritmo RSA, apenas a chave privada a pode decifrar, e vice-versa. Como com o esquema Certified Diffie-Hellman, o algoritmo RSA exige uma entidade de confiança para certificar e publicitar as chaves públicas do utilizador. Ao contrário de ambos os esquemas Diffie-Hellman, no entanto, o próprio algoritmo RSA não gera uma "chave de sessão" para ser utilizada simetricamente pelas partes. Em vez disso, a chave de cifra pública para um utilizador particular cifra directamente as comunicações para o utilizador e a chave de decifração privada do utilizador decifra as comunicações cifradas com a chave pública do utilizador. Desta maneira, o algoritmo RSA é um algoritmo de chave assimétrica puro.
No entanto, em virtude do algoritmo RSA ser complexo e envolver a exponenciação da mensagem por números muito grandes, o cifração e decifração de uma mensagem do mesmo comprimento moderado, utilizando o algoritmo RSA exige um grande período de tempo. Assim, é muito mais simples, rápido e eficiente utilizar o algoritmo assimétrico RSA para transportar uma chave de cifra DES para utilizar num algoritmo simétrico. Este modo de funcionamento de técnica anterior é conhecido como o transporte de chave RSA e é mostrado nas Figs. 5 e 6. Por exemplo, referindo a Fig. 5, um utiiizador podia gerar uma chave DES aleatória 51 e 86 259 ΕΡ Ο 759 560/ΡΤ 6
cifrar uma mensagem 52 com essa chave DES. O utilizador devia então cifrar a chave DES 51 com uma chave de cifração RSA pública 53 do utilizador de recepção pretendido e transmite a mensagem cifrada DES 54 junta com a chave DES cifrada RSA 55 para o utilizador de recepção. Depois de recepção da transmissão, como mostrado na Fig. 6, o receptor decifra a chave DES 51, utilizando a sua chave de decifração RSA privada 56 e utiliza a chave DES 51 para decifrar a mensagem 52. Em virtude do algoritmo DES exigir muito menos tempo e despesa para calcular do que o algoritmo RSA, a chave DES simétrica é utilizada para cifrar e decifrar a mensagem efectiva, enquanto as chaves RSA assimétricas são utilizadas para cifrar e decifrar a chave DES simétrica. O sistema de cifra de chaves púhlica/privada RSA fornece também uma “assinatura” digital que é dependente tanto da mensagem como do assinante, e pode ser utilizado para certificar que a mensagem recebida foi realmente enviada pelo remetente e que foi recebida inalterada. A assinatura digital RSA é baseada na propriedade adicional da RSA que, para além de permitir que a chave privada do utilizador decifre apenas as comunicações cifradas que utilizam a chave pública do utilizador, permite que a chave privada do utilizador cifre mensagens que podem ser decifradas apenas pela chave pública do utilizador. Devido a apenas o utilizador ter a chave privada, a utilização da chave privada para cifrar permite provar a origem, que pode ser verificada por qualquer pessoa com acesso à chave pública do utilizador. Na prática, o remetente utiliza primeiro a sua chave privada para codificar o texto da mensagem numa mensagem assinada, a qual não pode ser decifrada por qualquer pessoa, que não seja apenas do remetente. Se desejado, o remetente pode então utilizar opcionalmente a chave de cifra pública do receptor para cifrar a mensagem assinada para ser transmitida. Depois da recepção do texto cifrado, o receptor decifra o texto cifrado com a sua chave de decifração privada, se necessário, e descodifica a mensagem assinada com a chave de cifra pública do remetente. Visto que apenas o remetente conhece a sua chave privada única, apenas o remetente podia ter enviado a mensagem "assinada” particular; a assinatura verifica assim a identidade do remetente. Também, devido ao receptor apenas ter a chave pública do remetente, o remetente não pode reivindicar que o receptor ou uma terceira parte não autorizada tenha alterado ou inventado a sua mensagem; a assinatura evita assim a rejeição da mensagem pelo remetente. Para além disso, apenas a chave privada do remetente transforma a mensagem original e apenas o remetente conhece a sua única chave privada, nem o receptor nem uma terceira parte não autorizada podiam ter alterado a mensagem; a assinatura certifica assim a integridade da mensagem.
86 259 ΕΡ Ο 739 560/ΡΤ 7 Ο algoritmo RSA também fornece outro tipo de assinatura digital que utiliza uma função de endereçamento, calculada para criar uma compilação de mensagem curto, que é único para cada documento. As Figs. 7 e 8 mostram a criação da assinatura RSA e a verificação da assinatura RSA, respectivamente, utilizando uma função de endereçamento calculado. Uma função de endereçamento calculado é outro algoritmo matemático complexo que é de “uma via”, isto é, a fim de ser impossível reconstruir o documento a partir do resultado de endereço calculado, e é “sem colisão”, isto é, de modo que é impossível produzir outro documento que seja endereçado para a mesma compilação. Como mostrado na fig. 7, o remetente passa primeiro a mensagem 72 através de um algoritmo de endereçamento calculado 73 para produzir a compilação de mensagem 74 e depois cifra a compilação com a sua chave privada RSA 75, formando uma assinatura digital compacta 76, que é anexada à mensagem 72. Depois de receber a transmissão da mensagem 72 e a compilação da mensagem 76, como mostrado na Fig. 8, o receptor decifra a compilação da mensagem cifrada RSA do remetente 76 (a assinatura digital), utilizando a chave pública RSA do remetente 77. O receptor também utiliza o mesmo algoritmo de endereçamento calculado 73 para produzir uma compilação de mensagem 74 a partir da mensagem recebida. As duas compilações de mensagem resultantes das duas transformações realizadas pelo receptor devem ser idênticos, verificando assim que a mensagem foi assinada pelo remetente.
Outro sistema de assinatura digital, denominado DSA para algoritmo de assinatura digital (Digital Signature Algorithm, pode também ser utilizado para verificação do remetente. O algoritmo DSA foi descrito na patente U.S. n°. 5.231.668. O algoritmo DSA tem propriedades que são semelhantes às do algoritmo de assinatura RSA, em que o remetente passa a mensagem através de um algoritmo de endereçamento calculado para produzir uma compilação de mensagem e então cifrar ou assinalar a compilação de mensagem, utilizando a sua chave privada; o receptor verifica a compilação cifrada utilizando a chave pública do remetente. No entanto, diferente do algoritmo de assinatura RSA que devolve a compilação de mensagem original, quando o receptor decifra o bloco de assinatura, o algoritmo de verificação DSA resulta apenas numa confirmação positiva da validade da assinatura; as comunicações cifradas, utilizando uma chave pública do receptor pretendido não pode ser mais tarde recuperada através da decifração com a chave privada correspondente do receptor. Por esta razão, o algoritmo DSA pode ser utilizado de forma muito capaz para assinaturas digitais, mas não para transporte de chave ou para cifra de mensagem directa. 8 86 259 ΕΡ Ο 739 560/ΡΤ
De modo que ο sistema de chave pública/privada funcione de modo eficiente, os utilizadores devem confiar numa autoridade de certificação de chave centralizada, que seja responsável por publicitar e actualizar uma lista de endereços de chaves de cifra públicas. Todos os utilizadores devem confiar na autoridade de certificação de chave, tanto os remetentes como os receptores, para distribuir as chaves públicas correctas para todos os utilizadores, de modo que não sejam transmitidas quaisquer mensagens para receptores a quem não são dirigidas. Com esta finalidade, como explicado acima e descrito a seguir, a autoridade de certificação deve distribuir cada nome do utilizador e a informação de chave de cifra pública, e deve exibir a sua própria assinatura digital para a informação distribuída, a fim de certificar a falta de correcção da informação. No entanto, quando mais do que uma entidade, ou que uma hierarquia de entidades, está envolvida no processo de certificação, existem várias metodologias diferentes ou “modelos de confiança” para determinar como é que um utilizador processará os certificados. Os três modelos principais são (1) um modelo hierárquico puro, (2) um modelo que utiliza uma certificação cruzada entre hierarquias múltiplas, e (3) um modelo de “confiança local”. Estes modelos estão descritos em pormenor nas normas do documento American National Standard X9.30, “Public Key Cryptography Using Irreversible Algorithms for the Financial Services Industry: Part 3: Certificate Management for DSA” (American Bankers Assn., Washington, D.C., 1992). Embora não exista ainda um consenso geral sobre qual dos modelos acima mencionados de confiança é melhor, assume-se através desta descrição que um modelo de confiança de certificação apropriado, geralmente aceite, será estabelecido e terá a adesão a quaisquer certificados passados por mais do que uma entidade que estejam envolvidas. O sistema de chave público/privado descrito acima toma em conta os interesses de privacidade dos utilizadores, que desejam transmitir e receber comunicações privadamente. Adicionalmente, no entanto, existe também a força de lei e dos interesses de segurança nacional dos governos a serem considerados. A capacidade do governo para controlar ou escutar clandestinamente de qualquer outro modo transmissões electrónicas privadas por força da lei e finalidades de segurança nacional deve ser preservada de modo que aos criminosos suspeitos, aos terroristas e aos espiões estrangeiros não seja permitido conspirar por detrás do alcance da lei. Visto que as comunicações por telefone podem ser controladas através de escuta de fios, os algoritmos criptográficos fazem com que os dados cifrados não possam ser decifrados mesmo por computadores de violação de códigos poderosos. O aumento no volume e percentagem de transmissões digitais
86 259 ΕΡ Ο 739 560/ΡΤ 9 e digitatizadas cifradas com algoritmos avançados servirão, portanto, para frustar e impedir a vigilância electrónica legal do governo destas comunicações, especialmente se os dispositivos criptográficos forem amplamente implementados em telefones, computadores, máquinas de fac-símile e todos os outros equipamentos de processamento de dados.
Uma maneira de habilitar o governo ou outros investigadores autorizados para controlar comunicações de criminosos suspeitos é exigir a todos os utilizadores de comunicações criptográficas que garantam as suas chaves de decifração privadas com, ou uma autoridade privada, ou com o governo, isto é, permitir que ou a autoridade privada ou o governo sejam os guardas das chaves de decifração privadas dos utilizadores. Quando necessário para vigilância, o governo terá então acesso a, ou será capaz de conseguir ter acesso às chaves privadas a fim de controlar todas as comunicações cifradas. Este processo, no entanto, não é possível em virtude de conter insuficientes seguranças contra a violação pelo governo das chaves de decifração privadas e contra a possível fuga das chaves de decifração privadas para terceiras partes não autorizadas ou por roubo do governo ou da autoridade privada ou por corrupção do governo ou pessoal da autoridade privada.
Outro processo de garantir as chaves de decifração privadas para preservar tanto os interesses de privacidade do utilizador como os interesses de segurança da força de lei é através da utilização de um sistema tal como o processo descrito no "Fair Public Key Cryptosystems”, proposto por Silvio Micali em CRYPTO 92 em Março de 1993 e publicado pelo Laboratório para Ciência de Computação do Instituto de Tecnologia de Massachusetts em 13 de Outubro de 1993, e na Patente do Estados Unidos Nr. 5.276.737. Através deste processo, mostrado nas Figs. 9-11, um utilizador que queira certificar a sua chave pública com a finalidade de cifração deve certificar a sua chave privada da maneira seguinte. Como mostrado na Fig. 9, o utilizador divide primeiro a sua chave privada 91 em vários “pedaços” 92, cada um dos quais pode ser individualmente verificado 90 como sendo uma parte válida da chave privada 91. A chave privada pode ser reconstruída apenas com o conhecimento de todos os pedaços ou qualquer número específico dos mesmos. O utilizador envia então 93 cada pedaço para um agente de garantia ou agência 94, o qual, como mostrado na Fig. 10, verifica o pedaço como uma parte correcta da chave privada 91, utilizando um algoritmo especial e comunica esta verificação 96 para um centro de garantia principal. Referindo a Fig. 11, depois de receber a verificação 96, 97 de que cada pedaço da chave privada está correcto, o
86 259 ΕΡ Ο 739 560/ΡΤ 10 centro de garantia principal pode então passar um certificado 98 para a chave pública do utilizador 99, permitindo que a mesma seja utilizada num sistema privado com a certeza, se necessário for e de acordo com apenas com uma autorização da autoridade ou do tribunal, as agências de aplicação da lei são capazes de obter os pedaços secretos da chave privada a partir dos agentes de garantia escolhidos pelo utilizador, recombinar os mesmo e controlar as comunicações daquele utilizador. Através deste sistema, os utilizadores podem ficar certos da privacidade das suas transmissões cifradas, e o governo pode estar certo da sua capacidade de ter acesso a transmissões cifradas, quando tal se mostrar ser necessário. Em virtude de qualquer entidade nunca ter normalmente acesso à chave privada completa e em virtude do utilizador escolher entidades, nas quais ele confie, as hipóteses de acções ilegítimas ou corruptas ficam grandemente reduzidas. Também, em virtude de uma gama de entidades mais ampla serem elegíveis como agentes de garantia, as hipóteses de comprometer simultaneamente todos os agentes de garantia, e interromper portanto todo o comércio de confiança, é ainda mais reduzido. O centro de garantia principal, como uma autoridade de confiança que certifica a autenticidade da chave pública do utilizador, emite periodicamente um certificado disponível publicamente, atestando ou legalizando perante um notário a ligação entre a chave de cifra pública e a informação de identificação do dono seu. O certificado de autenticidade assegura ao remetente que as transmissões àquele chamado utilizador de chave pública poderá de facto ser recebido e lido apenas pelo receptor dedicado. O certificado está normalmente num formato eiectrónico reconhecido internacionalmente, tal como o especificado na Recomendação CCITT X.509 e publicado como uma norma internacional peta International Standards Organization (ISO). Um exemplo de um formato de certificado de garantia de chave de cifra pública é mostrado na Fig. 12. O certificado contém, entre outras coisas, o nome da organização ou centro de administração de chave que cria o certificado (o emissor) 121, a chave pública do dono 122, a informação de identificação do dono 126, um número de série do certificado 123, e datas de início e de fim da validade 124. A assinatura digital do emissor 125 “sela” o certificado e evita a sua alteração. O governo dos Estados Unidos, no entanto, propôs como uma norma do governo (e possivelmente da indústria) outro processo para facilitar a garantia das chaves de decifração privadas e para controlar as comunicações. O governo dos Estados Unidos desenvolveu um microcircuito, chamado o "Clipper chip” (pastilha electrónica Clipper), que pode ser incluído dentro de dispositivos de computador e
86 259 ΕΡ Ο 739 560/ΡΤ 11 de telefones produzidos comercialmente e para o governo. A pastilha electrónica Clipper é uma pastilha electrónica de baixo custo que pode ser utilizada para cifra em massa e administração de chave; a pastilha electrónica Capstone é uma versão mais avançada da pastilha electrónica que adiciona capacidades de assinatura digital e compilação de mensagem. Tal como outros sistemas de cifra, a pastilha electrónica Clipper utiliza um algoritmo de cifra simétrico, não obstante um algoritmo classificado chamado Skipjack, que mistura comunicações de dados de computador de telefone e digitais numa maneira semelhante ao DES, mas utilizando uma chave de 80 bit. Cada pastilha electrónica Clipper tem um número de série único, uma chave de família Clipper comum a todos as pastilhas electrónicas Clipper e a sua própria chave de dispositivo privada e simétrica, que será necessária pelas agencias governamentais autorizadas, a fim de descodificar mensagens codificadas por um dispositivo contendo a pastilha electrónica. Quando o dispositivo contendo a pastilha electrónica é fabricado, a chave de dispositivo privada única será dividida em dois componentes (chamados "divisões de chave") e depositados separadamente em duas bases de dados de garantia de chave ou agências que serão estabelecidas no governo. Os agentes das forças da lei podem ter acesso a estas chaves de dispositivo privadas através da obtenção de uma ordem ou outra autorização legal para escutar ou controlar as comunicações e através da apresentação da autorização às duas agências de garantia.
Quando os utilizadores dos dispositivos de pastilha electrónica Clipper desejarem comunicar, eles concordam, em primeiro lugar, com uma chave de sessão simétrica com a qual se cifram as comunicações. Qualquer processo de originar a chave de sessão simétrica, tal como o processo de derivação de chave de Interactive Diffie-Hellman, e pode ser utilizado qualquer processo de transportar a chave de sessão DES entre os utilizadores, tal como o transporte RSA. No início de cada comunicação, cada utilizador envia ao outro um campo de acesso de lei (LEAF), que contém informação suficiente para permitir que os agentes das forças da lei escutem ou controlem a comunicação. O formato acreditado do LEAF Clipper é mostrado na Fig. 13 (notar que em virtude dos pormenores precisos do formato LEAF, a criação e verificação são normalmente classificados de “secreto” pelo governo dos Estados Unidos, esta explicação e a Fig. 13 são ambas algo especulativas). Para formar o LEAF, a chave de sessão é primeiro cifrada utilizando a chave de dispositivo cifrada; depois a chave de sessão de dispositivo de chave cifrado, o número de série do dispositivo de remetente e uma soma de verificação (um valor de verificação) da chave de sessão não cifrada original são cifrados em conjunto com a chave de família Clipper para completar o LEAF. A mensagem é
86 259 ΕΡ Ο 739 560/ΡΤ então cifrada, utilizando a chave de sessão escolhida. A mensagem cifrada de chave de sessão e o LEAF de família de chave cifrada são transmitidos em conjunto para o receptor. Após recepção da comunicação, o utilizador de recepção carrega, em primeiro lugar, o LEAF recebido na sua pastilha electrónica Clipper, a fim de verificar se o LEAF é válido e se a chave de sessão cifrada dentro do LEAF coincide com a chave de sessão recebida anteriormente. Se o LEAF é válido, a pastilha electrónica Clipper decifrará a mensagem com a chave de sessão escolhida que foi recebida anteriormente.
Um agente das forças da lei que dentro da lei faça a escuta ou o controlo da comunicação, no entanto, não sabe a chave de sessão e, assim, deve, em primeiro lugar, decifrar o LEAF a fim de obter a chave de sessão. O agente intercepta o LEAF desejado, decifra o mesmo utilizando a chave de família Clipper e então apresenta o número de série da pastilha electrónica do LEAF e uma autorização de tribunal ou outra autorização legal aos dois agentes de garantia do governo, recebendo em troca as duas divisões de chave da chave de dispositivo privada do utilizador escutado. O agente combina os dois componentes de chave de dispositivo garantidos e utiliza a chave de dispositivo resultante para decifrar a chave de sessão de dispositivo de chave cifrada a partir do LEAF. A chave de sessão pode então ser utilizada para decifrar as mensagens efectivas a partir das comunicações. A exigência de que o remetente e o receptor criem cada um, um LEAF e validem o LEAF do outro, assegura que os agentes das forças da lei têm uma hipótese razoável de interceptar o LEAF, uma vez que se espera que cada LEAF passe entre os utilizadores através do mesmo meio de comunicação. Além disso, permite que se controle legal e selectivamente apenas um utilizador suspeito pela decifração do LEAF, gerado pelo utilizador, indiferentemente de que utilizador originou a comunicação.
Infelizmente, existem muitos problemas técnicos relativamente à proposta de pastilha electrónica Clipper do governo, a maior parte derivados do facto das chaves privadas a serem garantidas serem implantadas permanentemente nas pastilhas electrónicas Clipper durante o fabrico. Em virtude da chave de cifra privada para um dispositivo particular é queimada no interior da pastilha electrónica e não poder ser alterada, a pastilha electrónica e provavelmente todo o dispositivo que a contém deve ser descartado se comprometido. É preferível, para o utilizador de um dispositivo particular, ser capaz de repetir a chave, garantir de novo e certificar de novo o dispositivo como desejado, se existirem suspeitas de comprometimento ou em intervalos regulares para evitar potenciais 13 86 259 ΕΡ Ο 739 560/ΡΤ comprometimentos. Para além da incapacidade do utilizador de repetir e garantir de novo a chave, o utilizador do dispositivo Clipper não tem escolha no que se refere ao número ou às idenlidades dos agenles de yaranLia de chave, empregues pelo governo, para salvaguardar a sua chave privada. Em vez disso, as divisões de chave privada são depositadas em duas bases de dados de garantia ou agências estabelecidas pelo governo. Os utilizadores podem não confiar nos dispositivos de pastilha electrónica Clipper devido ao risco que o governo possa ter acesso completo a qualquer transmissão ou transacção através do dispositivo, acesso que pode ter uma má utilização ou ser corrompido. Os utilizadores podem também desejar que as suas chaves sejam garantidas com mais confiança do que a fornecida pelo governo, a fim de que as suas chaves privadas sejam mais seguras. Se o conceito de garantia de chave é ter significado, cada utilizador deve ter a possibilidade de escolher em quem confiar que garanta as suas chaves privadas, baseados no nível de confiança desejado.
Acredita-se também, que o sistema Clipper do governo permite aos utilizadores comunicar apenas simetricamente e em tempo real, e não fornece qualquer suporte directo para mensagens tipo correio electrónico, armazenadas e transmitidas. Antes da cifra das comunicações, o remetente e o receptor devem primeiro concordar numa chave de sessão simétrica com a qual cifram as comunicações. Tipicamente, esta troca de chave é feita utilizando o esquema Interactive Diffie-Hellman, o único processo de troca de chave, acreditado como sendo suportado peia pastilha electrónica Clipper. Assim, a menos que eles queiram dispor do seu próprio sistema de administração de chave, os utilizadores estão restringidos a comunicações simultâneas e interactivas, tal como voz em tempo real ou comunicações de telecópia. A fim de utilizar mensagens tipo correio electrónico armazenadas e transmitidas um utilizador deve, no entanto, ser capaz de aceder à chave pública do receptor pretendido, tal como através da utilização de um esquema de transporte de chave Certified Diffie-Hellman ou um RSA certificado, mesmo se o receptor dedicado não estiver disponível para uma comunicação em tempo real interactiva. Em virtude de se acreditar que o sistema Clipper do governo não facilita isto, as mensagens armazenadas e transmitidas são difíceis. O sistema padrão proposto do governo pode assim tender a limitar as capacidades de comunicações dos utilizadores de interacção em tempo real.
Além disso, com o sistema do governo, os empregadores dos utilizadores não têm acesso aos dados ou transmissões cifrados dos seus empregados. Os empregadores, em defesa dos quais os empregados estão a desenvolver,
86 259 ΕΡ Ο 739 560/ΡΤ comunicando ou transmitindo dados confidenciais ou de propriedade, devem conservar o direito a ter acesso às transmissões ou dados dos seus empregados. Muitas situações podem acontecer em que a informação cifrada está apenas disponível aos empregados específicos directamente comprometidos na utilização dos sistemas criptográficos e não para a administração ou concelho de directores, os quais são responsáveis por estes empregados e a quem pertencem os recursos de dados da corporação. Pela cifra de dados ou comunicações, os empregados podem desenvolver ou adequar para eles próprios novos programas, produtos e tecnologias ou podem levar a cabo actividades ilegais e transacções, tudo sem o conhecimento dos seus empregadores. O movimento ou a reorganização do pessoal e as mudanças das instalações de armazenagem podiam resultar na perda de grandes quantidades de informação, que era suficientemente importante na altura da cifra ser decifrada. Ver Donn B. Parker, “Crypto and Avoidance of Business Information Anarchy” (Apresentação do orador convidado na First Annual AC Conference on Computer and Communication Security, 3-5 de Novembro de 1993, Reston, VA). Além do originador dos dados ou do remetente das transmissões, a pastilha electrónica Clipper permite que apenas o governo tenha acesso ás transmissões. Embora os empregadores pudessem obter uma autorização do tribunal, a fim de controlar as comunicações dos seus empregados, os empregadores podem desejar controlar os seus funcionários internos de uma maneira mais discreta do que através do início de uma investigação federal de cada vez que haja suspeita.
Além disso, mandatar um algoritmo classificado que está incluído na pastilha electrónica e assim disponível apenas em suporte físico e apenas a partir de fabricantes de pastilhas electrónicas autorizados pelo governo introduz o governo dentro do mercado em rápida alteração e altamente competitivo para comunicações e suporte físico de computadores. Uma agência do governo ou um fabricante autorizado pelo governo pode não ser capaz ou não estar disposto a conceber dispositivos avançados no mercado e produtos especialmente feitos por encomenda para companhias particulares, como poderá estar um fabricante privado. Se o governo autorizar apenas certos vendedores a fabricar as pastilhas electrónicas tendo o algoritmo classificado, a competição será reduzida e a tecnologia será impedida de ser incluída noutros produtos. Adicionalmente, em virtude dos pormenores do algoritmo Skipjack não terem sido tornados públicos, suspeita-se, que o algoritmo possa ser inseguro, devido a erro de concepção ou à introdução deliberada pelo governo de um alçapão. Um valor importante da concepção do sistema de criptografia é que a privacidade e segurança das 15 86 259 ΕΡ Ο 739 560/ΡΤ mensagens cifradas deveriam depender do segredo dos valores de chave relevantes, não do segredo dos pormenores do sistema. É, portanto, desejável proporcionar um sistema de garantia de chave comercial, que utiliza algoritmos publicados, funciona de uma maneira que inspira segurança e confiança ao utilizador, e resolve os problemas postos pelas questões de segurança nacional e da lei.
Também é desejável fornecer um sistema de garantia de chave comercial, que utiliza chaves privadas que podem ser alteradas à vontade pelo utilizador ou em intervalos regulares. É ainda desejável proporcionar um sistema de garantia de chave comercial, que permite ao utilizador escolher os agentes de garantia de chave, para salvaguardar a sua chave privada ou os pedaços separados da sua chave privada. É ainda adicionalmente desejável proporcionar um sistema de garantia de chave comercial que contém salvaguardas contra o acesso do governo sem restrições, permite ainda acesso pelos empregados dos utilizadores ou pelos países dos quais os utilizadores estrangeiros são cidadãos. É também desejável proporcionar um sistema de garantia de chave comercial que ofereça uma alternativa ao sistema de pastilha electrónica Clipper proposto pelo Governo dos Estados Unidos.
RESUMO DQ INVENTO É um objectivo deste invento proporcionar um sistema de garantia de chave comercial, que utiliza algoritmos publicados, funciona de uma maneira que inspira a segurança e confiança, e resolve os problemas postos pelas exigências de segurança nacional e da lei. É outro objectivo deste invento proporcionar um sistema de garantia de chave comercial, que utiliza chaves privadas que podem ser alteradas à vontade pelo utilizador ou em intervalos regulares. É um objectivo adicional deste invento proporcionar um sistema de garantia de chave comercial, que permite ao utilizador escolher os agentes de garantia de
86 259 ΕΡ Ο 739 560/ΡΤ chave, para salvaguardar a sua chave privada ou pedaços separadas da sua chave privada. É ainda um objectivo adicional deste invento proporcionar um sistema de garantia de chave comercial, que contém salvaguardas contra o acesso do governo sem restrições, permitindo ainda acesso pelos empregados dos utilizadores ou pelos países dos quais os utilizadores estrangeiros são cidadãos. E ainda outro objectivo deste invento proporcionar um sistema de garantia de chave comercial que oferece uma alternativa ao sistema de pastilha electrónica Clipper proposto pelo Governo dos Estados Unidos.
Estes e outros objectivos do invento são conseguidos de acordo com os princípios do invento, proporcionando um sistema de garantia de chave criptográfica que utiliza um processo para geração, de modo que possa ser verificado com segurança, uma comunicação de fluxo orientado entre uma pluralidade de utilizadores, como definido nas reivindicações independentes. Algumas características preferidas são especificadas nas reivindicações dependentes.
BREVE DESCRICÃO DOS DESENHOS
Os objectos acima e outros e as vantagens do invento serão evidentes, tendo em consideração a descrição pormenorizada seguinte, em conjunto com os desenhos anexos, nos quais os caracteres de referência referem-se as partes semelhante através dos mesmos, e nos quais: as Figs 1A - 1G são listas de símbolos e abreviaturas que são utilizados nas figuras deste invento; a Fig. 2 é um fluxograma, que mostra os passos do processo de derivação de chave Interactive Diffie-Hellman da técnica anterior; a Fig. 3 é um fluxograma mostrando os passos da porção de certificação do processo Certified Diffie-Hellman da técnica anterior; a Fig. 4 é um fluxograma mostrando os passos da porção de mensagens do processo Certified Diffie-Hellman da técnica anterior; 17 ΕΡ Ο 739 560/ΡΤ a Fig. 5 é um fluxograma mostrando os passos de cifração utilizando o processo de transporte de chave RSA da técnica anterior; a Fig. 6 é um fluxograma mostrando os passos de decifração utilizando o processo de transporte de chave RSA da técnica anterior; a Fig. 7 é um fluxograma mostrando os passos de criação de assinatura utilizando o processo RSA da técnica anterior; a Fig. 8 é um fluxograma mostrando os passos de verificação de assinatura, utilizando o processo RSA da técnica anterior; as Figs. 9-11 são fluxogramas que em conjunto mostram os passos do processo de garantia de chave Micali da técnica anterior; a Fig. 12 é um exemplo do formato para um certificado de garantia de chave de cifra pública da técnica anterior; a Fig. 13 é um exemplo do formato acreditado do dispositivo Clipper do campo de acesso de lei (LEAF); a Fig. 14 é um exemplo do formato para um certificado de dispositivo, emitido pelos fabricantes do dispositivo do presente invento; a Fig. 15 é um fluxograma, que mostra os passos de um processo de garantia verificável de uma chave com apenas um agente de garantia; a Fig. 16 é um fluxograma, que mostra os passos de um processo de garantia verificável uma chave, com base apenas no dispositivo de confiança; a Fig. 17 é um fluxograma mostrando os passos de um processo de envio de uma mensagem cifrada com o cabeçalho de controlo de mensagem (MCH); a Fig. 18 é um exemplo de um MCH num formato de transporte de chave RSA; a Fig. 19 é um fluxograma, que mostra os passos de um processo de recepção de uma mensagem cifrada com um MCH;
86 259 ΕΡ Ο 739 560/ΡΤ 18 a Fig. 20 é um exemplo de uma caixa descodificador MCH e um fluxograma para o seu fluxo de processo; a Fig. 21 é um exemplo de um dispositivo de atribuição de selo de tempo de confiança e com certificação própria; a Fig. 22 é um exemplo do formato para um certificado de dono do dispositivo emitido pelo fabricante do dispositivo; a Fig. 23 é um fluxograma, que mostra os passos de um processo de garantir de novo uma chave (repetir a chave) pelo dono do dispositivo; e a Fig. 24 é um fluxograma, que mostra os passos de um processo para registo do dispositivo de confiança com uma terceira parte de confiança.
DESCRIÇÃO DETALHADA DO INVENTO
Os sistemas criptográficos de chave pública, que incluem a utilização de assinaturas digitais, podem ser potencialmente as pedras fundamentais da criação de sistemas de documentos electrónicos sem papel nacionais, ou mesmo globais. A utilização destes sistemas terá um enorme significado comercial em termos de poupança de custos. O elemento crítico no desenvolvimento e aceitação ampla destes sistemas é a confiança colocada nos sistemas criptográficos subjacentes e as assinaturas digitais pelos governos, bancos, corporações e outros utilizadores, incluindo utilizadores individuais. A confiança nestes sistemas deve aumentar não a partir da segurança por cada utilizador do seu próprio sistema interno ou de outros utilizadores, mas a partir da segurança por cada utilizador do sistema criptográfico de chave pública e dos mecanismos de certificação que o mesmo fornece. O sistema croptográfico comercial do presente invento satisfaz estas preocupações através da utilização da certificação própria e, portanto, dispositivos de cifração confiáveis como árbitros imparciais de confiança.
Um pastilha electrónica inviolável, ou um dispositivo de confiança inviolável contendo a pastilha electrónica, que realiza a cifração, decifração e assinatura digital está incluído com um par de chaves de assinatura pública/privada não modificável únicas para a pastilha electrónica e com um "certificado de fabricante". O certificado de fabricante incluído habilita o dispositivo que contém a pastilha electrónica (a) o "assinar" digitalmente documentos e comunicações ("estruturas de 19 86 259 ΕΡ Ο 739 560/ΡΤ dados") utilizando a sua própria chave de assinatura de dispositivo privado, provando que os mesmos são unicamente originados a partir deste dispositivo e (b) a provar através da anexação do certificado do fabricante a documentos e comunicações, que as estruturas de dados podem ter segurança, porque o dispositivo que origina as mesmas é um dispositivo de um tipo conhecido e de confiança e é feito pelo fabricante de confiança. O certificado do fabricante diz com efeito, "O dispositivo cuja chave privada combina com a chave pública aqui certificada é do tipo XXX. Assinado, o Fabricante". Em virtude da chave de assinatura privada estar incluída de uma maneira inviolável e em virtude do fabricante ser de confiança, os documentos e as comunicações emitidas pelo dispositivo e assinados utilizando a chave de assinatura privada serão também confiáveis.
Uma concretização preferida do presente invento será descrita com referência ao seguinte: (1) criação ou fabrico das pastilhas electrónicas contidos no dispositivos, (2) registo da chave de cifra do dispositivo em agentes de garantia, (3) cifração e decifração normal das mensagens do utilizador, (4) descodificação das comunicações por agentes das forças da lei, (5) repetição da chave e actualização do dispositivo pelo dono ou empregado, (6) auditoria das escutas legais, (7) cifração de dados com fluxo orientado, e (8) salvaguardas de segurança nacional.
Fabrico do dispositivo de confiança O fabrico de dispositivos confiáveis é baseado na presença das seguintes características gerais: (1) um microprocessador incluído (ou mícrocontrolador), um computador em miniatura que faz a mediação com todos os acessos exteriores e realiza várias operações de computação e de programação: (2) um coprocessador criptográfico opcional, o qual pode realizar operações de cifração e de decifração matemáticas normalizadas a uma velocidade muito mais alta do que pode o fazer um microprocessador de geral e o qual contém, de preferência, uma fonte de ruído de suporte físico, tal como uma fonte de ruído de díodo, para assistir à geração de números aleatórios certificáveis, como necessário para a geração da chave criptográfica; 20 86 259 ΕΡ Ο 739 560/ΡΤ (3) uma interface ou subsistema de entrada e saída para auxiliar o manuseamento do fluxo de dados e comandos para microprocessador e a partir do mesmo, o qual pode incluir um mostrador ou monitor de estado; e (4) um subsistema de memória, que pode empregar potencialmente vários tipos de tecnologia de armazenagem de memória, tendo cada um características diferentes de permanência e acessibilidade, tais como (a) memória apenas de leitura ("ROM"), que pode conter programas e dados permanentes e não alteráveis, (b) memória apenas de leitura programável e apagável electricamente ("EEPROM") ou memória "FLASH", que podem conter programas e dados semi-permanentes, isto é, as mesmas podem ser alteradas, mas no entanto não são perdidas quando é perdida a alimentação do dispositivo ou a mesma é desligada, e (c) memória de acesso aleatório ("RAM"), a quai pode ser utilizada para cálculos temporários e armazenagem de dados temporária, mas que é perdida quando a alimentação é desligada.
Todo o dispositivo é projectado e fabricado de tal modo que todos os seus elementos, incluindo especialmente as áreas de memória semi-permanentes e permanentes, são protegidos contra violação, que possa revelar os seus conteúdos ou alterar os seus modos de funcionamento. Uma maneira de proteger os elementos do dispositivo contra violação é através da utilização de revestimentos especiais que são difíceis de remover sem destruir a informação que está por debaixo dos revestimentos. Além disso, existem outras características que podem originar que a memória seja apagada se for tentada qualquer alteração ao conteúdo físico de qualquer das áreas de memória ou se ocorrerem acções suspeitas de violação do sinal, tal como arrefecer o dispositivo por baixas temperaturas anormais numa tentativa de desactivar e ultrapassar o mecanismo de defesa interna do dispositivo. Algumas destas características de protecção podem exigir uma fonte de alimentação de bateria constante, de modo que o dispositivo possa tomar acções eléctricas para apagar dados importantes se existir a suspeita de violação. O presente invento não especifica qualquer processo preferido particular para fazer os dispositivos resistentes à violação, mas antes conta com as tecnologias existentes ou futuras que podem ser ou se podem tornar visíveis geralmente como proporcionando um grau aceitável de protecção de descrições não autorizadas ou modificações dos dados contidos nos dispositivos. Um dispositivo com tais características é algumas vezes referido como um módulo seguro resistente a violação (TRSM), do qual um exemplo corrente é o dispositivo Clipper/Capstone, explicado antes, disponível comercialmente em Mykotronx, Inc. 21 86 259 ΕΡ Ο 739 560/ΡΤ Ο fabricante das pastilhas electrónicas pode ser qualquer um dos muitos fabricantes de pastilhas electrónicas de microprocessadores de computador principais. O fabricante pode ser, de preferência, um que seja conhecido na indústria criptográfica e seja de confiança em relação à qualidade e segurança das pastilhas electrónicas e à integridade do seu processo de fabrico.
As pastilhas electrónicas fabricadas a fim de serem utilizadas no processo, no qual o invento está incluído, incluem as seguintes capacidades. A pastilha electrónica deve, em primeiro lugar, incluir um par de chaves pública/privada de dispositivo incluído para as assinaturas de dispositivo serem emitidas pelo dispositivo, em que a chave de assinatura privada não é lida e é resistente a violação. As chaves de assinatura criptográfica podem ser de qualquer tipo criptográfico aceitável, tal como o RSA. No entanto, em virtude do RSA ter tanto as capacidades de assinatura como de cifração, e em virtude de ser desejável isolar os processos de assinatura e cifração, a chave de assinatura criptográfica deve ser, de preferência DSA. A pastilha electrónica deve incluir também um certificado do fabricante, incluído e resistente a violação, para a chave de assinatura de dispositivo, um exemplo do formato para isso é mostrado na Fig. 14. O dispositivo que contém a pastilha electrónica pode anexar este certificado para as suas assinaturas, a fim de provar que as assinaturas originadas a partir do dispositivo de um tipo conhecido e de confiança tendo as qualidades descritas abaixo.
Um pastilha electrónica fabricada a fim de ser utilizada no processo, no qual o presente invento está incluído deve também incluir a chave de verificação de assinatura pública do fabricante, incluída dentro da pastilha electrónica de uma maneira resistente a violação. A chave de assinatura pública do fabricante pode ser utilizada pelo utilizador para verificar as instruções recebidas de outros, pela verificação se as instruções estiveram anexas a uma assinatura digital válida criada pela chave de assinatura privada do fabricante, a fim de determinar se as instruções são originadas pelo fabricante ou por alguém em quem o fabricante confie. A pastilha electrónica pode também incluir chaves de instruções públicas e resistentes à violação que podem ser utilizadas pelo utilizador para verificar instruções recebidas a partir de outros. A chave de instruções pública pode ser a chave pública de algumas outras entidades confiáveis, tal como o "Bankers Trust Co.”, seleccionadas pelo fabricante ou pode ser a chave pública de uma autoridade nacional ou de sistema global de confiança, e pode em opção ser incluída numa pastilha electrónica pelo fabricante para utilização como um "atalho", para evitar a necessidade de verificar o certificado de fabricante para a entidade de confiança 22 86 259 ΕΡ Ο 739 560/ΡΤ extra. Ο fabricante pode instalar várias chaves de instrução de várias casas de garantia de chave qualificadas, que o fabricante selecciona e acredita que sejam capazes e confiáveis.
Além disso, a pastilha electrónica deve ter a capacidade de gerar um par de chaves pública e privada para cifração e decifração dos dados e comunicações pelo utilizador individual. As chaves criptográficas de cifração podem ser de qualquer tipo criptográfico assimétrico aceitável, tal como o RSA. As chaves criptográficas devem, no entanto, ser, de preferência, do tipo Diffie-Hellman, isto é, o número secreto do utilizador é a chave privada e o número intermédio publicitado do utilizador é a chave pública, as quais são utilizadas juntas no esquema Certified Diffie-Hellman para gerar uma chave de sessão, que é utilizada para cifração e decifração de comunicações. A chave privada assim gerada é depois armazenada dentro das pastilhas electrónicas de uma maneira não legível e resistente a violação. Adicionalmente, a pastilha electrónica deve ter também a possibilidade, uma vez que um par de chaves de cifração pública e privada para o dispositivo já foi gerada, para repetição da chave e geração de um novo par de chaves de cifração pública e privada no lugar do par de chaves anterior. Noutra concretização, pode também ser utilizada a geração de chave Interactive Diffie-Hellman, como explicado mais tarde, a fim de assegurar que todos os remetentes e receptores contribuem com novos números aleatórios para gerar as chaves de sessão de mensagem. O dispositivo de confiança pode ter a capacidade de decifrar as comunicações cifradas em apenas duas condições. A primeira condição é que o centro de garantia principal válido certifica para os dispositivos tanto do remetente como do receptor devem ter sido incluídos dentro do dispositivo, antes de terem recebido a transmissão cifrada. Cada certificado é válido se for assinado por um centro de garantia principal, que certifica que a chave de decifração privada do dispositivo foi garantido por um ou mais agentes de garantia qualificados e, de preferência, por dois ou mais agentes estilo Micali, que utilizam um protocolo de divisão de chave verificável. Este centro de garantia principal certifica se deve ser acompanhado por outro certificado, passado pelo fabricante estabelecendo o centro de garantia principal nomeado, como um agente de garantia válido, ou deve ser assinado por uma terceira parte (uma autoridade nacional de confiança ou um sistema global), nomeada como possuindo uma chave de instruções pública incluída na pastilha electrónica pelo fabricante. A segunda condição para decifração é que a mensagem a ser decifrada dcvc scr precedida por um campo de dados de 23 86 259 ΕΡ Ο 739 560/ΡΤ cabeçalho de controlo de mensagem (MCH) (para cujo formato será uma descrição mais tarde), a fim de que o pessoal de segurança do empregador e legal terá dados suficientes, a partir dos quais se obtêm as chaves privadas garantidas do receptor e logo o controlo da comunicação. A pastilha electrónica pode também ter a capacidade de gerar um par de chaves pública e privada para ser utilizado nas distintas assinaturas de utilizador, a partir do par de chaves incluídas, que é utilizado para as assinaturas de dispositivo. Como com o par de chaves de assinatura de dispositivo, as chaves de assinatura de utilizador criptográfico pode ser de qualquer tipo criptográfico aceitável, tal como o RSA, mas deviam, de preferência, ser DSA, de novo para evitar qualquer possível confusão com as chaves utilizadas para a cifração de mensagens. A chave privada de assinatura de utilizador deve ser ilegível e resistente a violação. O utilizador deve utilizar a chave privada de assinatura para assinar as suas comunicações para verificação de remetente e fins de não repúdio. A pastilha electrónica pode ter também a capacidade de utilizar a chave de assinatura de dispositivo, a fim de assinar um pedido de certificação da chave de assinatura pública de utilizador, que foi gerada pelo utilizador, provando assim que o par de chaves de assinatura do utilizador foi gerado por um dispositivo com propriedades de resistência a violação conhecidas e a chave privada está a ser salvaguardada pelo mesmo. A pastilha electrónica pode também ter uma fonte de ruído de suporte físico, tal como uma fonte de ruído de díodos, para gerar números aleatórios durante a geração de chave, e um único número de série de dispositivo físico, para permitir que o dispositivo ou as suas acções sejam seguidas por sistemas contabilisticos, de administração de redes e de inventário. Neste caso, a assinatura de dispositivo deve certificar não apenas que o dispositivo do utilizador tem propriedades resistentes a violação conhecidas, mas também que todas as chaves ou números aleatórios gerados pelo dispositivo foram gerados aleatoriamente, utilizando um gerador de números aleatórios de alta qualidade, de preferência uma fonte de ruído de díodo.
No fabrico do dispositivo de confiança, que contém a pastilha electrónica, a memória da pastilha electrónica é dividida em, pelo menos, três áreas gerais como se segue: (1) espaço de memória não alterável e permanente, que contém dados e suporte lógico inalterável, incluídos dentro da pastilha electrónica durante o fabrico; (2) espaço de memória alterável e semi-permanente, que contém dados, tais como as chaves de assinatura e cifra privada do utilizador, geradas para o utilizador e
86 259 ΕΡ Ο 739 560/ΡΤ mantidas com confiança para o utilizador pela pastilha electrónica, dados e chaves os quais podem ser utilizados pela pastilha electrónica para fazer assinaturas digitais, ou para decifrar para o utilizador, mas os quais não são nunca descritos fora do dispositivo; e (3) espaço de memória temporária e não permanente, que contém uma área de trabalho utilizada para armazenagem temporária das entradas, resultados intermédios e resultados finais de várias operações de processamento de dados. Dependendo da concepção, estas áreas gerais podem cada uma existir dentro de um tipo diferente de sistema de armazenagem de memória, tal como a ROM para os dados permanentes, memória EEPROM ou FLASH para dados de utilizador, conservados em confiança, e RAM para armazenagem temporária volátil. Outra abordagem pode ser utilizar a memória FLASH para os dados tanto permanentes como não permanentes. Ainda uma outra opção é utilizar um sistema de operação de pastilha electrónica que deve gerir a memória de microprocessador, utilizando uma directoria de objectos. Com esta abordagem, uma porção de memória pode ser dedicado a uma tabela ou directoria dos outros itens na memória e pode incluir informação normalizada para cada objecto, tal como: - nome lógico (por exemplo, "chave pública do fabricante"); - tipo (por exemplo, chave, certificado, rotina de código, etc.); - endereço de início e comprimento de dados (em bytes); - última data modificada (opcional); - nível de protecção (permanente, utilizador ou volátil); - nível de descrição (legível extemamente ou não legível externamente).
Desta maneira, sempre que a memória completa está igualmente resistente a violação, não é necessário conceber áreas especiais para os dados protegidos ou não protegidos em virtude do microprocessador poder rapidamente reforçar o nível desejado de protecção, com base no código, contido na entrada de directoria relevante para o objecto de dados. Este esquema pode também ser aplicado a rotinas de código suporte lógico inalterável, quase tão facilmente como a dados, e pode ser com vantagem aplicado quando se renovam ou substituem rotinas de 25 86 259 ΕΡ Ο 739 560/ΡΤ código suporte lógico inalterável confiáveis, sem a necessidade de substituir fisicamente o dispositivo ou qualquer das suas unidades de memória.
As áreas de memória protegidas do dispositivo podem conter os seguintes tipos de informação, incluindo os códigos de programa de dados e suporte lógico inalterável. A. Inserida permanentemente pelo fabricante 1. Pode ser descrita extemamente a. chave pública de autoridade de sistema geral (opcional) b. chave pública de fabricante c. certificado de fabricante da autoridade de sistema geral d. chave pública de dispositivo e. certificado de dispositivo do fabricante f. número de série único de dispositivo g. números de versão suporte lógico inalterável h. chaves de instrução pública de banco de confiança 2. Não pode ser descrita externamente a. chave de assinatura privada de dispositivo 3. Suporte lógico inalterável a. sistema de operação e sistema de ficheiro b. rotinas de biblioteca criptográfica básicas c. rotinas de sistema de garantia 26 86 259 ΕΡ Ο 739 560/ΡΤ d. outro código de aplicações de confiança B. Gerada por operações de utilizador e mantido em confiança para o utilizador 1. Pode ser Externamente Descrita a. chave de cifra pública do utilizador b. certificado de garantia de chave de cifra pública do utilizador c. chave de assinatura pública do utilizador d. certificado de chave de assinatura pública do utilizador 2. Não pode ser Externamente Descrita a. chave de decifração privada do utilizador b. chave de assinatura privada do utilizador C. Outra Armazenagem Ler Escrever Não Volátil a. certificados de assinatura dos correspondentes b. certificados de garantia dos correspondentes c. certificados de dispositivo dos correspondentes (para verificação MCH) D. Armazenagem de Trabalho (Podia ser Volátih
As chaves públicas (todos os tipos), os certificados (todos os tipos), os valores de informação não válida, os blocos de assinatura, as outras estruturas de dados a serem processadas. 27 86 259 ΕΡ Ο 739 560/ΡΤ
Processo de Garantia de Chave
Depois da pastilha electrónica ter sido fabricada e antes de utilizar a pastilha electrónica para cifrar ou decifrar comunicações, a chave de decifração pública do utilizador deve ser registada com um centro de garantia principal ou com agentes de garantia, aprovados pelo fabricante da pastilha electrónica. Ou o próprio utilizador pode realizar esta operação ou o fabricante pode iniciar e registar a pastilha electrónica num agente de garantia durante o fabrico, evitando assim ao próprio utilizador a exigência de garantir as suas chaves. No entanto, o próprio fabricante podia ainda deixar ao utilizador a opção de repetir a chave numa altura posterior. Para muitos utilizadores individuais, permitindo ao fabricante registar a pastilha electrónica, com ou sem uma opção de repetir a chave, será suficiente. Além disso, os consumidores deveriam muito provavelmente confiar nos agentes de garantia escolhidos pelo fabricante da pastilha electrónica. As corporações ou outros empregados podem programar as suas próprias pastilhas electrónicas e as pastilhas electrónicas dos seus empregados, e podiam registar as pastilhas electrónicas em agentes de garantia da sua própria escolha. As corporações, no entanto, não deveriam geralmente permitir que os seus empregados repitam as chaves eles próprios, porque isto podia resultar na perda de controlo sobre a informação e créditos corporativos, como explicado acima. A fim de gerar e registar uma chave de decifração, o utilizador (ou uma qualquer entidade que realize a operação) invoca um programa de suporte lógico inalterável, que foi incluído na pastilha electrónica e que dá instruções à pastilha electrónica para realizar os passos particulares do processo de garantia de chave Micali ou o processo de garantia de chave específico que é utilizado. Ver as Figs. 9 a11,15e16. Utilizando qualquer processo escolhido para garantira chave privada com um ou mais agentes de garantia, a pastilha electrónica gerará primeiro aleatoriamente, ou escolherá, um número secreto que será a chave de decifração privada para o utilizador (bem como os outros, números públicos que serão exigidos, se os números não foram já ajustados por alguma outra geração aleatória anterior). A pastilha electrónica armazenará a chave privada de uma maneira não legível e resistente a violação. Como mostrado na Fig. 15, a chave de decifração privada pode ser garantida num único agente de garantia. O dispositivo de confiança 150 gera primeiro um par de chaves de cifra pública/privada 151 para o utilizador e envia então para o centro de garantia 153 uma mensagem cifrada e assinada 152 consistindo no par de chaves de cifra 151 e o número de série do dispositivo 154, com o certificado do fabricante 155 para verificação da assinatura. 28 86 259 ΕΡ Ο 739 560/ΡΤ Ο centro de garantia 153 verifica as assinaturas, decifra o pacote de mensagem e armazena a chave de decifração privada do utilizador. O centro de garantia 153 envia também para o utilizador o certificado assinado 156, consistindo no número de série do dispositivo do utilizador 154 e na chave de cifra pública do utilizador 151 e a chave de verificação de assinatura pública do dispositivo 157, com o certificado do centro de garantia 158 para verificação de assinatura. Uma vez que o dispositivo do utilizador verifica a assinatura do centro de garantia, o registo fica completo.
Se a chave privada é para ser garantida em mais do que um agente de garantia, então a pastilha electrónica partirá então a chave privada em vários pedaços chamadas divisões de chave, de acordo com uma fórmula específica. Utilizando o processo de garantia Micali e o algoritmo descritos antes e mostrados na Fig. 9, a pastilha electrónica calculará então certos valores 90 utilizando o algoritmo Micali especial, a fim de que cada valor é apoiado numa transformação matemática de um dos pedaços da chave privada 92. A pastilha electrónica forma então um pacote de partilha para cada agente de confiança ou de garantia 94, indicado pelo utilizador, contendo cada pacote de partilha 93 o único número de série do dispositivo do utilizador, uma divisão de chave privada e o conjunto de certos valores que permitem ao agente de confiança particular verificar a divisão de chave privada recebida como uma parte válida da chave privada completa, sem dar conhecimento ao agente de confiança da chave privada completa. Como explicado mais tarde, se o utilizador não é o dono do dispositivo, mas em vez disso, por exemplo, um empregado do dono e empregador, o pacote de partilha de confiança deve também incluir o número de identificação único do dono do dispositivo e o certificado do dono do dispositivo, a fim de que o dono e empregador pode obter a chave privada do utilizador e empregado sem ter de primeiro obter uma autorização. A pastilha electrónica assina então cada pacote de partilha de confiança utilizando a única chave de assinatura privada de dispositivo e anexa o certificado do fabricante à pastilha electrónica de transmissão, atestando em consequência que a informação transmitida originada de um dispositivo de um tipo conhecido e de confiança. Finalmente, a pastilha electrónica enviará cada pacote de partilha de confiança assinado para entrega pelo utilizador a um agente de garantia e de confiança.
Existe uma outra maneira preferida do centro de garantia principal verificar as divisões de chave separadas, sem utilizar o processo Micali, contando apenas com o dispositivo de confiança. Utilizando este processo de verificação das divisões de chave, mostrado na Fig. 16, a pastilha electrónica gera um número aleatório 29 86 260 ΕΡ 0 739 560/ΡΤ para cada divisão de chave da chave de cifra privada. A pastilha electrónica forma então um pacote de partilha 161 para cada agente de garantia e de confiança 163, indicado pelo utilizador, que contém cada pacote o número do dispositivo do utilizador único, uma divisão de chave privada e um dos números aleatórios. A pastilha electrónica assina cada pacote de partilha de confiança utilizando a chave de assinatura privada de dispositivo única e anexa o certificado do fabricante 162 da pastilha electrónica de transmissão, atestando portando que a informação transmitida é originada de um dispositivo de tipo conhecido e de confiança. Como com o processo Micali, a pastilha electrónica enviará então cada pacote de partilha de confiança assinado 161, para entrega pelo utilizador a um agente de garantia e de confiança 163. Adicionalmente, a pastilha electrónica deve também criar uma mensagem (cifrada) 164 para o centro de garantia principal 165, que contém, entre outras coisas, a chave de cifra pública de utilizador e os nomes dos agentes de garantia indicados pelo utilizador e em conjunto com o número aleatório dado com as divisões de chave a cada agente de garantia respectivo. É possível, no entanto, em virtude de cada pacote de partilha de confiança conter uma divisão de chave privada, que uma terceira parte com acesso a comunicações de um utilizador até os agentes de garantia possa ler os conteúdos de todos os pacotes de partilha de utilizador e recombinar as divisões de chave privada dentro dos pacotes a fim de reagrupar a chave privada completa. Então, utilizando a chave privada, a terceira parte podia decifrar e cifrar comunicações em nome do utilizador. O melhor caminho para evitar esta situação é através da utilização de sistemas de comunicações cifradas, quando se enviam pacotes de partilha a partir de utilizadores para agentes de garantia. O utilizador deve obter o certificado de chave de cifra pública 166 de cada agente de garantia seleccionado, para garantir a chave privada de utilizador, onde cada certificado é assinado pelo centro de garantia principal, certificando que o agente de garantia particular é de confiança para o centro de garantia principal, para receber e armazenar um pacote de divisão de chave, e deve então verificar a assinatura de centro de garantia principal ou utilizando um certificado a partir do fabricante do dispositivo (ou a partir de uma autoridade de sistema geral) ou utilizando uma chave de instruções previamente incluída. O dispositivo deve então cifrar, para cada agente de garantia com base na chave de cifra pública certificada do agente, uma transmissão 161 que inclui o pacote de partilha de chave privada de utilizador. Em alternativa, o fabricante pode inserir na pastilha electrónica as chaves de cifra públicas de vários agentes de garantia confiáveis, que coincidentes com uma chave de instruções para cada um deles, como explicado anteriormente, com a finalidade do utilizador
86 259 ΕΡ Ο 739 560/ΡΤ 30 enviar as suas divisões de chave privada a agentes de garantia de confiança do possuidor das chaves de instruções, o qual é tipicamente o centro de garantia principal. Desta maneira, todos os agentes de garantia na "família" do centro de garantia principal ou do fabricante podem decifrar os pedidos de utilizador para garantir, enquanto poupa ao utilizador a carga de obter os certificados de chave de cifra pública de todos os agentes de garantia.
Uma vez que cada agente de garantia ou de confiança 163 recebe o pacote de partilha apropriado 161 a partir do utilizador ou do dispositivo de utilizador, o agente de confiança inspecciona a divisão de chave privada recebida no pacote de divisão de confiança 161, a partir do dispositivo de utilizador e, em conjunto com o centro de garantia principal 165, verifica que é uma parte válida e correcta da chave privada completa. É necessário para os agentes de garantia e centro de garantia principal terem meios confiáveis de fornecer ou verificar que os fragmentos da chave de decifração privada do utilizador foram de facto depositados. É desejável que a verificação das divisões de chave sejam conseguidas pelos agentes de garantia e pelo centro de garantia principal sem nunca inspeccionarem ou possuírem eles próprios os fragmentos, ou nunca os juntarem numa localização. O sistema de garantia "Distinto" Micali fornece uma maneira altamente de confiança para o centro de garantia verificar os depósitos separados dos fragmentos de chave. No processo Micali, mostrado nas Figs. 10 e 11, esta verificação é feita com o conjunto de certos valores, que foram calculados pela pastilha electrónica do utilizador, durante a preparação do pacote de partilha através da utilização de um algoritmo Micali especial e que foram incluídos com a divisão de chave em cada pacote de partilha para os agentes de garantia. O algoritmo Micali e a verificação de divisão de chave são conhecidos na técnica e não necessitam de ser repetidos aqui. Cada agente de confiança 94 armazena então o certificado do fabricante de dispositivo, para utilização posterior na descodificação, e aprova a divisão de chave 93, através do envio de uma mensagem assinada apropriada 96, para o centro de garantia principal, em conjunto com o nome de utilizador e o certificado de dispositivo, e pela assinatura e armazenagem da divisão de chave 90. Apenas quando apresentado com quer (a) uma autorização ou ordem de tribunal quer (b) um pedido assinado do dono legítimo do dispositivo, o agente de confiança revelará o pedaço (ou pedaços) de uma dada chave de decifração privada na sua posse.
Utilizando o processo de garantia e verificação preferido, contando apenas com o dispositivo de confiança, mostrado na Fig. 16, cada agente de confiança 163 transmite uma mensagem 167 para o centro de garantia principal 165 identificando 31 86 259 ΕΡ Ο 739 560/ΡΤ ο nome do utilizador, chave de cífração pública, número de dispositivo e o número aleatório que ele recebeu. Além disso, o dispositivo de utilizador envia um pacote para o centro de garantia principal 1G5, contendo os números aleatórios utilizados para a verificação das divisões de chave privada, e o pacote deve ser cifrado, utilizando a chave de cifra pública do centro de garantia principal. O centro de garantia principal 165 recebe as mensagens 164, 167 do dispositivo de utilizador e dos agentes de confiança 163, e verifica que o número individual aleatório recebido de cada agente de confiança combina o número aleatório, que o dispositivo de utilizador declarado deu ao agente de confiança. De notar que com este processo os agentes de garantia 163 e o centro de garantia principal 165 contam unicamente com a assinatura de dispositivo de confiança nos pacotes de partilha 161, para se assegurarem de que a garantia é apropriada. Este processo de garantia e verificação não precisa de realizar quaisquer operações matemáticas secundárias, para verificar que a garantia é apropriada ou que a chave pública, apresentada para certificação, se combina com os fragmentos de chave depositados. Embora, do ponto de vista do público, confiança de utilizador ou sistema geral, pode ainda ser desejável utilizar um algoritmo de garantia de chave, verificável tal como o processo Micali, não é claramente necessário e pode-se passar sem o mesmo, quando o custo adicional da utilização de um tal processo não pode ser justificado. Além disso, através deste processo com base apenas no dispositivo de confiança, não existe limite para a complexidade dos esquemas de divisão de chave que podem ser inventados, porque não há necessidade de inventar algoritmos secundários complexos para verificar o desempenho correcto de qualquer esquema dado. É necessário apenas confiar na integridade do fabricante de dispositivo, que tem incluído o código de suporte lógico inalterável e confiar que o dispositivo resiste a violação.
Depois de verificar todas as divisões de chave privada de utilizador, o próprio centro de garantia principal aprova ainda a chave de cifração pública que corresponde à chave de cifração privada, que foi aprovada por todos os agentes de confiança do utilizador; o centro de garantia principal 165 aprova a chave pública através da emissão de um certificado assinado 168 (chamado certificado de centro de garantia principal, certificado de chave de cifração pública, ou simplesmente, o certificado de garantia), que certifica que a chave privada correspondendo à chave pública a ser certificada foi já garantida de uma maneira apropriada. A chave de assinatura pública do dispositivo do utilizador, obtida a partir do certificado do fabricante do dispositivo, pode também ser colocada no certificado do centro de garantia principal, eliminando assim a necessidade de enviar ou tomar a verificar o 32 86 259 ΕΡ Ο 739 560/ΡΤ certificado do fabricante do dispositivo em pontos mais tarde no processo. O certificado de centro de garantia principal podia ser formatado como se segue: Número de versão Número de série do certificado de garantia Código de país do centro de garantia principal Nome do centro de garantia principal
Chave de cifração pública de centro de garantia principal (para utilizar na criação do LEAF)
Nome distinto do utilizador
Chave de cifração pública de utilizador (sendo aqui certificada)
Chave de verificação de assinatura pública de dispositivo de utilizador (para verificar a assinatura de dispositivo)
Data de validade (início/fim)
Assinatura de centro de garantia principal [Certificado de sistema geral de centro de garantia principal]
Os certificados de chave de cifração pública, que foram emitidos pelo centro de garantia principal, são distribuídos e podem ser utilizados ou pelo dono do dispositivo, a fim de activar o seu dispositivo para originar mensagens cifradas, ou por outros para cifrar mensagens para o dono do dispositivo, contendo o par de chave de cifração pública/privada de utilizador.
Deve ser notado que não há necessidade de que mais do que um agente de garantia seja o receptor das divisões de chave de cifração privada de utilizador; em alguns casos, pode ser suficiente simplesmente depositar a chave de decifração privada de utilizador com um único agente de garantia (ou centro de garantia). No entanto, a fim de melhorar a confiança do utilizador e do público no sistema, é desejável dividir a chave de decifração privada de utilizador entre vários agentes de garantia, a fim de todas as divisões de chave, ou algum número específico das mesmas, que são necessárias a fim de juntar a chave de utilizador e decifrar as suas comunicações. É ainda desejável que cada agente de garantia seja uma operação de negócio de confiança, independente, efectuando, desse modo, o "conhecimento dividido", a fim de que ao acontecer uma tentativa de corrupção, suborno, extorsão ou abuso, será muito mais difícil obter falsamente a chave de decifração privada de utilizador do que seria se a chave privada estivesse armazenada numa única entidade. É também desejável que as entidades estejam 33 8G 259 ΕΡ Ο 739 560/ΡΤ separadas geograficamente a fim de suprimir ainda as tentativas de subversão ou corrupção.
Cifracão de Comunicações
Um utilizador, que deseja enviar uma comunicação cifrada para outro utilizador, deve ter um certificado de garantia para o seu próprio dispositivo e um certificado de garantia para a chave de cifra pública de receptor pretendido, em virtude do dispositivo do presente invento nunca cifrar ou decifrar se qualquer deles faltar. Primeiro, o remetente deve carregar o seu próprio certificado válido no dispositivo, tipicamente, quando ele recebe o mesmo, em primeiro lugar, do centro de garantia principal. Então, o certificado de chave pública de receptor pretendido pode ser obtido ou a partir do receptor pretendido directamente, a partir de um serviço de directório listando chaves públicas, ou a partir do ficheiro local do remetente, por exemplo, um ficheiro de utilizadores, com quem o remetente trocou anteriormente comunicações cifradas. Num exemplo, porque um dispositivo do remetente não cifrará e o dispositivo de receptor não decifrará a não ser que o certificado de chave de cifra pública do receptor esteja “válido”, a fim do dispositivo de receptor decifrar a mensagem cifrada, o certificado de chave de cifra pública do receptor deve ser assinada por (a) o fabricante do dispositivo receptor (esta não deve ser a melhor situação, em virtude dos fabricantes do dispositivo não estarão provavelmente a garantir as chaves privadas de utilizador); (b) o centro de garantia principal, e acompanhado pelo certificado de fabricante, que aprova o centro de garantia principal como um centro de confiança válido; ou (c) um centro de garantia principal ou de confiança cuja chave de instruções foi incluída no dispositivo durante o fabrico. Utilizando a chave de cifra pública certificada de receptor pretendido como estabelecido no certificado de chave de cifra do receptor, o utilizador remetente gera então uma chave de sessão, para utilização tanto pelo remetente como pelo receptor, para cifrar e decifrar a comunicação. Esta chave de sessão pode ser gerada de preferência utilizando o processo Certified Diffie-Hellman ou, em alternativa, qualquer outro sistema equivalente. No processo Certified Diffie-Hellman, o utilizador gera, em primeiro lugar aleatoriamente a sua chave privada efémera para a mensagem e depois calcula a chave de sessão, apoiada na sua própria chave privada e na chave pública de receptor (isto é, o número intermédio de receptor e os dois números públicos, os quais estão todos contidos no certificado de chave de cifra pública de receptor). Então, utilizando a chave de sessão, o remetente cifra a mensagem a ser enviada para o utilizador de recepção. 34 86 250 ΕΡ 0 739 560/ΡΤ
No entanto, ao decidir se enviar ou não uma mensagem cifrada para o receptor pretendido, o remetente pode não ser capaz de verificar as propriedades do certificado de chave de cifra pública do receptor, ou das assinaturas digitais no mesmo, se o dispositivo do remetente for feito por um fabricante diferente do que fez o dispositivo do receptor. O facto de que, o dispositivo do receptor foi feito por um fabricante diferente, evita que o dispositivo do remetente verifique se a assinatura de fabricante ou o certificado do fabricante (que certificou o centro de garantia principal, que assinou o certificado de garantia de chave de receptor), declarando que o centro de garantia principal do receptor é válido e está aprovado pelo fabricante. Do mesmo modo, a pastilha electrónica do receptor não deve ser capaz de verificar estas condições em relação ao certificado do remetente antes da decifração. A implementação da restrição de garantia em ambas as partes é necessária, a fim de permitir aos agentes das forças da lei interceptar legalmente e decifrar mensagens, sendo tanto enviadas como recebidas por um dado utilizador suspeito, sem obter necessariamente a chave de decifração privada da outra parte não monitorizada e, desse modo, aceder às mensagens não relacionadas da parte não monitorizada.
Uma maneira para endereçar este resultado, enquanto que ainda se permite mais do que um fabricante para fazer dispositivos criptográficos, é incluir no dispositivo ou num certificado, emitido quer pelo centro de garantia principal do utilizador quer pelo fabricante de pastilha electrónica, uma chave pública de uma entidade nacional de confiança, por exemplo o Banco de Reserva federal ("FRB’’), o qual pode ser utilizado para verificar ainda outro certificado emitido pelo FRB para cada um dos outros vários centros de garantia principais ou fabricantes. Um tal certificado deve verificar a exactidão do centro de garantia principal particular ou fabricante e deve ser assinado pelo FRB. Um utilizador remetente pode então obter o certificado de chave de cifra pública de um receptor pretendido e pode confiar no centro de garantia principal que emitiu o certificado, porque o centro de garantia principal foi aceite pelo FRB, em vez de pelo fabricante de pastilha electrónica, como certificado pelo certificado ou chave pública FRB. Também, a assinatura de um dispositivo particular podia ser de confiança porque o outro fabricante que certificou o dispositivo foi aceite pelo FRB, como certificado pela chave pública ou certificado FRB. A fim de lidar com esta questão num nível menos paroquial com base nos Estados Unidos e promover um sistema mais internacional e geral, a chave pública de uma entidade global de confiança, tal como o "Bank for International Settlements" na Suíça, pode ser incluído no dispositivo de confiança, o certificado FRB ou o centro dc garantia principal ou o certificado de fabricante
86 259 ΕΡ Ο 739 560/ΡΤ (dependendo do modelo de confiança empregue), e pode funcionar da mesma maneira explicada com vista à chave FRB, a fim de aceitar os centros de garantia principais e fabricantes numa base geral. Outra maneira, para além de uma que não envolve as autoridades dos Estados Unidos ou mundiais, para um dispositivo confiar nos centros de garantia certificados por outro fabricante, é para os fabricantes de dispositivo ou os centros de garantia principais cruzarem certificados ente si. Isto deve permitir ao dispositivo de remetente ajudar a reforçar as restrições de garantia de receptor ao permitir que o dispositivo de remetente verifique a via de certificação do certificado de garantia de receptor de retorno através do fabricante de dispositivo de receptor ou do centro de garantia principal para si próprio. Num exemplo preferido, a chave pública de uma entidade de confiança de sistema geral deve ser incluída num dispositivo de confiança e deve funcionar da mesma maneira que a explicada acima no que se refere à chave de entidade global ou FRB, a fim de aceitar todos os centros de garantia principais e fabricantes numa base de sistema geral.
Sempre que qualquer utilizador, entidade ou dispositivo "verifica" um "certificado” assinado digitalmente, quer um certificado de fabricante quer um certificado de garantia, emitido por uma autoridade ou fabricante de certificação, é prática comum na maioria ou em todos os sistemas de administração de certificado de chave pública proposta (e é assumida completamente esta descrição), que o utilizador, entidade ou dispositivo também verifica qualquer "lista de revogação de certificados" ("CLR") aplicável, a fim de determinar se a autoridade de certificação ou outro emissor distribuiu, propagou ou de qualquer outro modo tornou disponível uma lista de certificados revogados, que é actualizada de acordo com uma política de segurança apropriada e se, apoiada no nome do emissor e número de certificado, o certificado foi revogado. Um certificado emitido para um utilizador pode ser revogado por morte, alteração de nome ou de emprego, ou perda, roubo ou destruição do dispositivo (o cartão inteligente pessoal) contendo a chave privada. Um certificado emitido para uma entidade pode ser revogado devido ao cessar do negócio, alteração do nome, ou perda, roubo ou destruição do dispositivo contendo a chave privada. Um certificado emitido para um dispositivo pode ser revogado devido à perda, roubo, remoção do serviço ou destruição do dispositivo. A verificação dos CRL durante a verificação de certificado está bem descrita na literatura pública (por exemplo, ANSI X9.30 - Parte 3) e não exige explicação adicional. Todos os utilizadores, entidades e dispositivos terão normalmente acesso a instalações de telecomunicações apropriadas e podem recuperar os CRL ou realizar inquéritos como desejado. De modo semelhante, com o presente invento, 36 86 259 ΕΡ Ο 739 560/ΡΤ presume-se que todas as entidades que emitem os CLR, os tornem disponíveis a todas as partes interessadas.
Formato de cabeçalho de controlo de mensagem
Quando se envia uma comunicação cifrada, o utilizador remetente deve também formar um campo de cabeçalho de controlo de mensagem (MCH) adequado, contendo a seguinte informação: (1) O número intermédio de remetente para a mensagem cifrada, calculado pelo remetente, que utiliza a chave privada efémera gerada aleatoriamente pelo remetente, que foi também utilizada pelo remetente para calcular a chave de sessão com a qual a mensagem foi cifrada. O utilizador de recepção tem de ter este número intermédio a fim de calcular a chave de sessão para decifrar a mensagem. (2) O nome e código de país do centro de garantia principal de remetente. (3) O nome e código de país do centro de garantia principal do receptor, obtidos a partir do certificado de chave pública de receptor. (4) O número de certificado de garantia do remetente, cifrado utilizando a chave de cifra pública do centro de garantia principal de remetente (obtida a partir do certificado de garantia de remetente) a fim de que apenas o centro de garantia principal de remetente a pode decifrar. (5) O número intermédio de remetente (diferente do número intermédio anterior de remetente), que foi utilizado pelo remetente para calcular a chave de sessão efémera com a qual o número de certificado de remetente foi cifrado para o centro de garantia principal do remetente. O centro de garantia principal do remetente tem de ter este número, a fim de calcular a chave efémera para decifrar o número de certificado do remetente. (6) A chave de sessão para a mensagem cifrada, cifrada utilizando a chave pública própria de remetente (o número intermédio do certificado público próprio do remetente), de modo que com efeito o remetente envia a chave de sessão de mensagem para si próprio. As forças da lei podem ter acesso a esta chave de sessão de mensagem uma vez que a mesma obtém os componentes de chave privada de remetente a partir dos agentes de garantia de remetente.
86 259 ΕΡ Ο 739 560/ΡΤ (7) Ο número intermédio de remetente (diferente dos dois anteriores números intermédios de remetente), que foi utilizado pelo remetente para calcular a chave efémera com a qual a chave de sessão de mensagem foi cifrada para ele próprio. A força da lei tem de ter este número a fim de calcular, utilizando também a chave privada de remetente (o seu número secreto) obtida a partir do centro de garantia principal do remetente, a chave efémera para decifrar a chave de sessão de mensagem. (8) O número de certificado de receptor, cifrado utilizando a chave de cifra pública do centro de garantia principal do receptor (obtida a partir do certificado de garantia do receptor), de modo que apenas o centro de garantia principal de receptor o pode decifrar. (9) O número intermédio de remetente (diferente dos três números intermédios anteriores do remetente) que foi utilizado pelo remetente para calcular a chave efémera com a qual o número de certificado de garantia de receptor foi cifrado para o centro de garantia principal do receptor. O centro de garantia principal de receptor tem de ter este número a fim de calcular a chave de sessão efémera, para decifrar o número de certificado do receptor. (10) Selo de tempo (opcional), para seguir os fins e possibilidade de auxiliar na implementação da data de garantia e restrições de tempo. (11) A assinatura do dispositivo do remetente. (12) O certificado de garantia de chave pública do remetente emitido pelo centro de garantia principal do remetente. O certificado de garantia de remetente contém a chave de assinatura pública de dispositivo de remetente, a qual o centro de garantia principal fez uma pré verificação e reproduziu então a partir do certificado do fabricante do dispositivo do remetente. (13) O certificado do centro de garantia principal a partir do FRB, o fabricante ou uma qualquer autoridade de sistema geral é de confiança, se a pastilha electrónica do receptor é feito por um fabricante diferente, anexo ao certificado de garantia do remetente. O certificado do fabricante, o FRB ou a autoridade de sistema geral é necessária apenas para a primeira comunicação entre as duas partes. O certificado pode ser também um certificado cruzado do fabricante ou o centro de garantia principal do receptor. 38 ΕΡ Ο 739 560/ΡΤ Ο MCH assim descrito podia ser resumido como segue: Número intermédio de remetente (para permitir que o receplor decifre a mensagem) Código de país de centro de garantia principal de remetente Nome de centro de garantia principal de remetente Código de país de centro de garantia principal de receptor Nome de centro de garantia principal de receptor Número de certificado de garantia de remetente, cifrado para o centro de garantia principal de remetente Número intermédio de remetente (para cifrar o número de certificado de remetente)
Chave de sessão de mensagem, cifrada para remetente Número intermédio de remetente (para cifrar a chave de sessão de mensagem para o remetente) Número de certificado de garantia de receptor, cifrado para o centro de garantia principal de receptor Número intermédio de remetente (para cifrar o número de certificado de receptor)
Selo de tempo
Assinatura MCH de dispositivo de remetente [Certificado de garantia de remetente] [Certificado de centro de garantia] A Fig. 17 mostra um processo para envio de uma mensagem cifrada 176 com um MCH. O MCH completo 172 (os certificados anexos 173, 174,175 não são tecnicamente parte do MCH) é assinado pelo dispositivo do remetente 171, utilizando a chave de assinatura DSA privada de dispositivo, com o certificado incluído do fabricante, anexo à mesma (dentro do certificado de garantia do remetente), a fim de certificar a chave de assinatura pública do dispositivo. Isto garante que todo o MCH é entregue intacto para o receptor e que a pastilha electrónica do receptor pode facilmente verificar que o MCH não foi modificado. O certificado do fabricante pode ser acompanhado por um certificado nacional (FRB) ou da autoridade mundial para certificar a exactidão do fabricante da pastilha electrónica do remetente, no caso do dispositivo do receptor ser fabricado por um fabricante diferente.
86 259 ΕΡ Ο 739 560/ΡΤ 39
Um segundo, formato MCH mais curto pode ser utilizado para o caso, em que não é crucial uma privacidade total. Neste MCH, nem o número de certificado de remetente nem o número de certificado de receptor são cifrados para o respectivo centro de garantia principal. O não cifrar os números de certificado poupa muito tempo e espaço na criação do MCH. Ainda numa outra concretização deste invento, um terceiro formato MCH ainda mais curto pode ser utilizado um para o caso comum, no qual o remetente e o receptor utilizam ambos o mesmo centro de garantia principal para fins de garantia de chave, ao fazer o EC1 semelhante ao EC2. Pela eliminação da necessidade no MCH de identificação da informação do segundo centro de garantia principal e para o número intermédio especial, que é utilizado para cifrar o número de certificado de receptor para o segundo centro de garantia principal, o MCH pode ser feito de modo significativamente mais curto. Para além disso, o tamanho do MCH pode ser mais reduzido através da utilização do transporte de chave RSA para cifrar uma chave DES para a mensagem e para cada um dos três componentes LEAF interiores cifrados. De acordo com este processo, cada número intermédio de remetente deve ser substituído por uma chave DES com envolvimento RSA mais pequena. Assim, o remetente podia cifrar RSA a chave de sessão de mensagem para o receptor e eliminar a necessidade do primeiro número intermédio no MCH. O remetente pode também cifrar em RSA a chave de sessão de mensagem para si próprio (de facto, para as forças da lei para decifrar mais tarde) e assim eliminar a necessidade do terceiro número intermédio no MCH. O remetente pode ainda cifrar em RSA os seus próprios números e os números de certificado do receptor e assim eliminar a necessidade do segundo e quarto números intermédios no MCH. Como mostrado na Fig. 18, eliminando os quatro números intermédios e a sua cifração associada e substituindo cada número intermédio com uma cifra de transporte RSA mais pequena 181 poupa uma quantidade significativa de espaço do tamanho do MCH.
Contribuição de material aleatório
Alguém pode estar preocupado que uma chave de sessão de mensagem trocada, utilizando apenas o processo de transporte de chave RSA ou o esquema Certified Diffie-Hellman, não seja suficientemente segura, porque, com qualquer destes dois processos, embora tanto o remetente como o receptor fornecem informação, apenas o remetente gera a chave de sessão de mensagem. No entanto, com os padrões militares para comunicações seguras, tanto o remetente como o receptor devem contribuir com material aleatório na geração de uma chave de sessão, antes de cada sessão de comunicação, a fim de aparentemente reduzir
86 259 ΕΡ Ο 739 560/ΡΤ 40 a hipótese do remetente poder utilizar uma chave fraca ou utilizar a mesma chave repetidamente e portanto sujeitar o receptor a um risco de segurança indesejável contra a sua vontade. O sistema de dispositivos de confiança descritos aqui podem aliviar este temor de duas maneiras. Primeiro, o mesmo pode assegurar que o dispositivo remetente deverá gerar cada chave separadamente, utilizando números aleatórios derivados do ruído de uma fonte de ruído de suporte físico incluída, tal como um díodo de polarização invertida, como explicado anteriormente. Depois, logo que o dispositivo assine o MCH ou cabeçalho de controlo de mensagem, o receptor deve estar seguro que cada chave de sessão de mensagem e os números aleatórios utilizados na geração da mesma são fortes e únicos. Ainda, os que insistem numa maior segurança podem pedir uma contribuição de material aleatório para ambos os lados da comunicação, como definido para sistemas militares Tipo 1, para informação classificada.
Assim, longe desta descrição, o remetente foi descrito como gerando as chaves de sessão de mensagem, com base na chave de cifra pública do receptor, como contida no seu certificado de garantia, mas não se baseia no material aleatório recebido do receptor durante a fase de ajustamento da comunicação. Fazendo os preparativos para que o remetente receba uma contribuição do receptor, no entanto, cria um novo problema. O receptor não pode simplesmente ser autorizado a gerar um número intermédio Diffie-Hellman por si próprio e enviá-lo para o remetente para utilizar na geração de uma chave de sessão de mensagem, porque o receptor então não pode utilizar mais a chave privada garantida dentro do seu dispositivo de confiança para decifrar mensagens e porque as suas comunicações nunca podem ser controladas pela as forças da lei. O sucesso continuado em forçar o esquema de garantia exige que nem o remetente nem o receptor sejam capazes de ler uma mensagem sem utilizar um dispositivo de confiança registado. A fim de permitir uma situação na qual tanto o remetente como o receptor contribuem com material aleatório para a chave de sessão de mensagem antes de comunicarem, o protocolo de troca de chave inicial pode ser modificado, a fim de permitir um suposto dispositivo de receptor para gerar um novo número secreto Diffie-Hellman efémero, separado e afastado da chave privada garantida do receptor, que será utilizado para calcular um novo número intermédio, que será enviado de novo para o remetente para utilização no cálculo da chave de sessão de mensagem para cifrar a mensagem. A chave privada garantida de receptor deve ainda ser utilizada para gerar os números intermédios (incluídos no MCH) e as
86 259 ΕΡ Ο 739 560/ΡΤ 41 chaves de sessão efémera, que são utilizadas para cifrar as várias porções do MCH. Esta modificação exige, no entanto, que a geração do novo número secreto ocorra dentro do suposto dispositivo de receplor, que este novo número secreto permaneça dentro do dispositivo de confiança, e que o novo número intermédio seja assinado pelo suposto dispositivo de receptor, antes de ser enviado para o dispositivo do remetente com a finalidade de atestar que o novo número secreto efémero está sem dúvida seguramente confinado dentro do dispositivo do receptor. Como anteriormente, o dispositivo do remetente gera um novo número secreto, que está separado e longe da chave privada garantida de remetente e, utilizando o novo número secreto e o novo número intermédio de receptor, gera a chave de sessão de mensagem para decifrar a mensagem. O dispositivo do remetente deverá também utilizar o novo número secreto de remetente para gerar o novo número intermédio de remetente, o qual deverá ser enviado para o dispositivo receptor como um elemento do MCH com a finalidade de escuta. Neste processo, a chave de sessão de mensagem deveria, portanto, incluir material aleatório para o qual contribuíram ambos o remetente e o receptor, como desejado.
No entanto, com este protocolo de troca de chave modificado, porque o receptor e o remetente utilizam com efeito novas chaves privadas Diffie-Hellman para cada mensagem, a característica garantia ainda "desaparece", na medida em que as forças da lei e a administração corporativa nunca serão capazes de obter as chaves de sessão de mensagem efémera, a partir dos agentes de garantia. Portanto, as necessidades do sistema de garantia e da comunhão de interesses exigem que a chave de sessão de mensagem seja transportada no MCH como anteriormente. De facto, para assegurar a igualdade de escuta, todos os campos que foram antes descritos como parte do MCH ficam assim. O campo que transporta a chave de sessão de mensagem para o remetente (a qual é a única maneira dos agentes das forças da lei que estão a escutar o remetente lerem a mensagem) deve ser ainda incluído no MCH a fim de preservar o princípio da igualdade de escuta. A chave de sessão de mensagem será cifrada no MCH, como anteriormente, utilizando a chave de cifração pública do remetente, para a qual as forças da lei têm ainda acesso. O novo número intermédio do remetente deverá ser enviado para o receptor como o primeiro elemento do MCH, como anteriormente, a fim de permitir que as forças da lei escutem o receptor e calculem a chave de sessão de mensagem. Assim, a fim de conciliar a técnica de troca de chave Diffie-Hellman Interactiva, este protocolo exige que o suposto novo número intermédio do receptor seja gerado dentro do seu dispositivo e seja assinado pelo mesmo, e exige que o novo número intermédio do remetente seja adicionado ao MCH, não utilizado
86 259 ΕΡ Ο 739 560/ΡΤ 42 em lugar dos processos de transporte de chave indicados anteriormente, visto que é o único processo para que a comunidade de interesses (as forças da lei, os empregados e outros) possam ler a mensagem. Este processo, no entanto, não deve ser económico para as transacções a não ser para as transacções de telefone, redes, ou negócios de acesso telefónico em tempo real, porque o dispositivo deve ter de se lembrar de muita coisa, isto é, os números intermédios especiais para cada parte contrária. Este processo é, de preferência, para ser utilizado em telefones celulares, inícios de sessão de rede, etc, através dos quais é desejada uma sessão interactiva puramente em tempo real.
Comunidade dos cabeçalhos de interesse O MCH deverá geralmente ser colocado antes da mensagem cifrada, como um cabeçalho de mensagem. Em muitos sistemas de correio electrónico normal e de documentos, vários receptores estão habilitados a ler uma mensagem codificada, utilizando a concretização de transporte RSA da concepção MCH como explicado acima, através da cifra RSA da chave de sessão de mensagem, utilizando a chave de cifra pública de cada receptor. Isto é, quando vários receptores têm intenção de receber a mesma mensagem cifrada, o cabeçalho MCH pode incluir, para cada receptor pretendido, o nome do receptor pretendido, seguido pela chave de sessão de mensagem, cifrada RSA para cada receptor pretendido utilizando a chave de cifração pública do receptor. Assim, cada receptor pretendido pode localizar a sua entrada no cabeçalho MCH, decifrar a sua cópia da chave de sessão de mensagem e ler a mensagem. Mesmo com vários receptores pretendidos, a correcção do MCH é implementada em ambas as extremidades da comunicação: na extremidade remetente, a saída MCH é implementada pela lógica interna do dispositivo do remetente, isto é, a exigência de que o mesmo crie um MCH válido antes de cifrar uma mensagem; na extremidade receptora, a correcção MCH é implementada pela verificação pelo dispositivo do receptor da assinatura digital do dispositivo do remetente. Como notado anteriormente, porque as cópias de receptor da chave de mensagem estão integradas no MCH, nenhum receptor pode decifrar a mensagem a menos que o MCH seja enviado e recebido intacto, de modo diferente do sistema Clipper, no qual o próprio MCH não está ligado ao mecanismo de transporte de chave.
Sob este conceito de formatação de MCH, o MCH pode ser resumido como mostrado na Fig. 25. Como nos formatos MCH anteriores, a autenticidade do MCH é garantida pela assinatura digital do dispositivo do remetente 258. Para além
86 259 ΕΡ Ο 739 560/ΡΤ 43 disso, como antes, os números de certificado de garantia do remetente e do receptor são cifrados com as chaves de cifração públicas dos seus respectivos centros de garantia principais 251, 252. Nesle formalo, no entanto, o MCH, assinado pelo dispositivo do remetente, torna-se uma "lista de receptores" modificada que é mais flexível e mais fácil de compreender em relação ao trabalho de sistemas de correio electrónico cifrado ao mesmo tempo. Por exemplo, os nomes do remetente e do receptor (ou as ID ou endereços de sistema) são agora mostrados não cifrados no MCH 253, 254. Embora isto choque com o anonimato do remetente e do receptor, como uma questão prática é difícil enviar mensagens num sistema de correio electrónico sem pôr nas mensagens os nomes e os endereços dos remetente e receptor. Por isso a perda de privacidade é ligeira. Além disso, os nomes dos empregados dos remetente e receptor 255, 256 (ou as suas únicas ID, tal como os números de contribuinte ou números DUNS) são também mostrados não cifrados, reduzindo assim grandemente a tarefa do grupo de segurança dos empregadores, para encontrar mensagens enviadas e recebidas pelos seus respectivos empregados. Em alternativa, em vez de deixar os blocos de nome do remetente, receptor e empregador não cifrados, estas entradas podem apenas ler "remetente", "destinatário", "empregador do remetente" e "empregador do receptor" (ou os seus equivalentes) não cifradas, com os identificadores efectivos dentro das áreas cifradas, como anteriormente. Assim, um receptor pretendido da comunicação deve procurar no MCH a sua abreviatura de identificação não cifrada e desta maneira tentará decifrar e ler apenas as porções do MCH que são dirigidas e cifradas para ele.
Adicionalmente, este formato MCH, como mostrado na Fig. 25 permite o acesso por possíveis sub-unidades dentro da organização do empregador, através da definição de linhas de empregador secundárias (a, b, etc.). Para empregadores conscientes da segurança, o MCH pode ler "sub-unidade de empregador remetente b” não cifrada, como explicado acima, e conter o identificador de unidade de companhia efectivo na área cifrada. Em virtude de cada MCH estar etiquetado, não existe limite de quantas camadas de acesso de empregador podem existir; todas se tornam de alguma maneira "receptores" autorizados da mensagem. Além disso, pelo contrário, para os formatos MCH anteriores, este formato MCH pode incluir a chave de sessão de mensagem cifrada directamente para o empregador 257, a fim de que o empregador não necessita de ir ao centro de garantia principal e agentes para obter a chave de sessão de mensagem para decifrar a mensagem. Embora possivelmente chocando com as expectativas de privacidade do empregado no 44 86 259 ΕΡ Ο 739 560/ΡΤ lugar de trabalho, este formato pode permitir aos empregadores verificar ou recuperar os ficheiros dos seus empregados com um esforço mínimo. A fim de criar um MCH neste formato antes do envio de uma comunicação, o remetente deve primeiro obter todos os nomes/códigos e chaves públicas necessários dos receptores pretendidos e dos seus empregadores. Esta informação pode ser guardada a partir do certificado de garantia do receptor e a partir do seu próprio certificado de garantia. No entanto, a fim de generalizar esta abordagem e tornar esta informação disponível para um utilizador que deseje enviar uma comunicação, os centros de garantia principais devem incluir dentro de cada certificado de garantia de forma padrão do utilizador, como explicado anteriormente, a identificação ou número de código e chave de cifração pública únicos tanto do seu empregador como quaisquer sub-unidades de empregador. O esquema de certificado de garantia pode ser concebido através da utilização de subgrupos repetitivos, para manuseamento eficiente dos números variáveis de partes da "comunidade de interesses". Cada entrada de parte da comunidade de interesses deve ter um número de identificação, uma chave de cifração pública e, possivelmente, um código de instrução (ou código de plano de acção, como explicado abaixo) únicos, que dá instruções ao dispositivo do remetente de como codificar a entrada MCH da parte. O código de instruções pode incluir elementos de escolha, dando ao dispositivo remetente as opções de incluir (1) o número de identificação único da parte ou não cifrado ou utilizando um nome suposto, por exemplo "emp-a"; (2) a chave de sessão de mensagem na área codificada ou não; (3) o número de identificação único da parte na área codificada ou não; e (4) o número de atribuição de selo de tempo ou aleatório no início da área codificada ou não. Estes códigos de instruções (e possivelmente outros) podiam ser definidos como sinalizadores de máscara de bit. A lista de partes (e/ou os seus códigos), as suas chaves de cifração pública e os sinalizadores de instrução deveriam dizer ao dispositivo do remetente como formatar as porções da comunidade de interesses do MCH de acordo com os desejos de cada parte para um anonimato parcial ou total. É antecipado que na prática, muitas partes da comunidade de interesses não se devem preocupar com o anonimato, porque deverá ser muito mais fácil para eles procurá-los e identificar as mensagens dos seus empregados se eles mantiverem os seus próprios nomes e números de identificação em claro. 45 86 259 ΕΡ Ο 739 560/ΡΤ
Decifração por Receptores
Quando o receptor pretendido recebe a mensagem cifrada 191 e o campo MCH 192, devem ser feitas várias coisas a fim do receptor ler a mensagem, como mostrado na Fig. 19. Primeiro, o receptor deve carregar o seu próprio certificado de garantia válido 193 dentro da sua pastilha electrónica 190 porque, num exemplo, a pastilha electrónica não decifrará sem o mesmo. Tipicamente, o certificado de garantia de receptor deverá estar já armazenado na memória do dispositivo num estado previamente verificado. O receptor carrega em seguida o MCH 192 e o certificado de garantia de remetente 194, o qual também contém a chave de verificação de assinatura pública de dispositivo do remetente (com o certificado de autoridade de sistema geral, nacional ou mundial apropriado 195, se necessário) dentro da sua pastilha electrónica 190. A pastilha electrónica 190 do receptor verifica o certificado de garantia 194 do remetente a fim de verificar que a chave de decifração privada de remetente foi garantida. Isto é feito através da utilização da chave pública do fabricante para verificar a assinatura do fabricante no certificado do dispositivo ou, se necessário, a assinatura da autoridade de sistema geral no certificado de centro de garantia e através da verificação se a assinatura do centro de garantia no certificado de garantia do remetente é válido. A chave de assinatura pública 196 da autoridade de sistema geral pode ser utilizada para verificar directamente o certificado de garantia 195. A pastilha electrónica do receptor verifica então a assinatura de MCH antes de proceder a fim de verificar que (1) o dispositivo remetente é de confiança, (2) a chave do remetente está garantida, como também verificado pelo remetente, e (3) o MCH 192 é válido, isto é o MCH tem o formato próprio e contém todas as informações requeridas. Isto é feito através da verificação da assinatura de dispositivo do remetente, a assinatura de certificado do fabricante de dispositivo do remetente e, se necessário, o certificado de autoridade de sistema geral do fabricante. As chaves públicas do fabricante e do autoridade de sistema geral podiam ser incluídas na pastilha electrónica 190 do receptor para facilitar este processo de verificação. No caso mais simples, o receptor precisa de validar o certificado de garantia 194 do remetente apenas uma vez, contra a sua própria chave pública do fabricante, incluída ou a chave de instruções de entidade de confiança de sistema geral. Uma vez que estas são mostradas para serem válidas para um remetente particular, o receptor precisa apenas de utilizar a chave pública de dispositivo previamente validada do remetente para validar a assinatura MCH, resultando apenas numa única validação de assinatura por mensagem. Se quer o certificado de remetente 194 quer o MCH 192 é inválido, a pastilha electrónica do receptor não deverá decifrar a mensagem. 46 86 259 ΕΡ Ο 739 560/ΡΤ
Finalmente, depois da verificação estes certificados e assinaturas, o receptor calcula a chave de sessão de mensagem, com base no número intermédio do remetente, o qual foi incluído no MCH, e a própria chave privada do receptor (o seu número secreto), que corresponde à sua chave pública como publicitado no seu certificado de chave de cifração pública 193. utilizando a chave de sessão, o receptor decifra a mensagem enviada pelo utilizador de envio.
Decifração pelas forças da lei A fim de interceptar e decifrar comunicações para e a partir de um utilizador particular, as forças da lei devem ter uma autorização do tribunal ou uma autorização para monitorizar as comunicações do utilizador particular. A autorização do tribunal deverá, com toda a probabilidade, incluir (1) uma data de "inicio da monitorização" e o tempo, durante o qual as forças da lei podem começar a monitorizar as comunicações do utilizador, (2) uma data "final da monitorização" e o tempo depois após o qual as forças da lei não podem monitorizar as comunicações do utilizador, e possivelmente (3) um período de graça para seguir a data "final da monitorização ", podendo durante período de graça as forças da lei reter a chave privada do utilizador, a fim de apenas decifrarem as comunicações previamente interceptadas, mas não para interceptar ou monitorizar quaisquer comunicações adicionais desse utilizador. Na monitorização das comunicações do utilizador remetente, as forças da lei interceptam a comunicação e identificam a partir do MCH o nome e país do centro de garantia principal do remetente a fim de determinarem a quem exigir a chave de decifração privada do remetente. As forças da lei apresentam então a autorização do tribunal e o MCH da comunicação interceptada ao centro de garantia principal de remetente, o qual utiliza a sua chave privada para decifrar o número de certificado do remetente, que foi cifrado dentro do MCH. Utilizando o número de certificado do remetente, o centro de garantia principal de remetente procura o nome do utilizador remetente e os nomes dos agentes de garantia do remetente, e revela-os todos ao agente das forças da lei em conjunto com o certificado de fabricante de dispositivo do remetente, o qual as forças da lei deverão precisar mais tarde durante a descodificação. O agente das forças da lei contacta então cada um dos agentes de garantia do remetente e apresenta a eles o nome do remetente e a autorização, e obtém de cada agente de garantia as divisões de chave confiadas a eles pelo remetente. Em virtude do processo de intercepção e decifração das comunicações cifradas pelas forças da lei pode utilizar a caixa descodificadora especificada abaixo, a exigência das forças da lei aos agentes de garantia deverá também incluir a chave de cifração pública da 86 259 ΕΡ Ο 739 560/ΡΤ 47
caixa descodificadora das forças da lei, a fim de que as divisões de chave possam ser enviadas directamente para a caixa descodificadora das forças da lei, e não para os próprios agentes das forças da lei. Cada agente de garantia envia a divisão de chave do remetente na sua posse para a caixa descodificadora das forças da lei como uma mensagem cifrada tendo uma data de "início da monitorização", uma data de "paragem da monitorização" e um "período de graça" opcional, de modo que a caixa descodificadora possa reforçar os termos da autorização. A caixa descodificadora decifra então as mensagens de divisão de chave cifradas, combina as divisões de chave e utiliza a chave privada junta de novo do remetente para obter a chave de sessão para a comunicação, tendo sido a chave de sessão cifrada pelo remetente para o MCH como uma mensagem enviada para si próprio. A caixa descodificadora pode então monitorizar e interceptar as comunicações para e do remetente apenas durante o período de monitorização especificado na autorização, e pode continuar a decifrar as comunicações interceptadas apenas até ao fim do período de graça especificado na autorização.
Um procedimento semelhante é utilizado para monitorizar comunicações para e do receptor. A partir do MCH da comunicação interceptada, as forças da lei identificam o nome e o país do centro de garantia principal do remetente e apresentam então a autorização e o MCH a partir da comunicação interceptada ao centro de garantia principal do receptor, o qual utiliza a sua chave privada para decifrar o número de certificado do receptor, que foi cifrado no MCH. Utilizando o número de certificado do receptor, o centro de garantia principal do receptor procura o nome do receptor e os nomes dos seus agentes de garantia e revela-os todos ao agente das forças da lei. O agente das forças da lei contacta então cada um dos agentes de garantia do receptor e apresenta-lhes o nome do receptor e a autorização. Cada agente de garantia envia a divisão de chave, a ele confiada pelo utilizador receptor, para a caixa descodificadora das forças da Iei como uma mensagem cifrada para a caixa descodificadora, que tem uma data de "início da monitorização ", uma data de "paragem da monitorização " e um período de graça para vigor dos termos da autorização pela caixa descodificadora. A caixa descodificadora decifra então as divisões de chave cifradas, combina-as e utiliza a chave privada remontada resultante do receptor, em conjunta com o número intermédio do remetente, o qual está no cabeçalho de cada MCH, para calcular a chave de sessão para a comunicação. A caixa descodificadora pode então controlar e interceptar comunicações para e a partir do receptor apenas durante o período de monitorização especificado na autorização, e pode continuar a decifrar
86 259 ΕΡ Ο 739 560/ΡΤ 48 as comunicações interceptadas apenas até ao fim do período de graça na autorização. O formato para cada mensagem de divisão de chave cifrada de agente de garantia para a caixa descodificadora de implementação de lei pode ser como segue: Número de certificado do utilizador Fragmento de chave privada: X(i)
Data e hora de início da monitorização Data e hora de paragem da monitorização Período de graça permitido por tribunal (dias/horas)
Data e hora (desta mensagem de divisão de chave)
Assinatura do agente de garantia [Certificado do agente de garantia]
Neste formato, toda a informação excepto para o número de certificado deveria ser cifrada com a chave de cifração da caixa descodificadora. Em virtude das mensagens de divisão de chave dos agentes de garantia serem cifradas para a caixa descodificadora particular, nenhum outro utilizador ou caixa descodificadora pode lar as mesmas. Além disso, as datas e horas de "início da monitorização" e de "paragem da monitorização" dão instruções à caixa descodificadora quando deve começar a monitorização e descodificação das comunicações e quando deve parar a monitorização; o período de graça permite à caixa descodificadora um período de tempo especificado e adicional para descodificar qualquer registo posterior das comunicações previamente interceptadas, devendo depois do período de tempo a caixa descodificadora parar a descodificação e deve limpar a chave privada do sujeito. Assim, a chave descodificadora pode ser utilizada para decifrar as comunicações do utilizador, controladas até à data especificada na autorização, tempo no qual a caixa descodificadora e o seu relógio de tempo incluído evita qualquer decifração adicional. A caixa descodificadora pode também recusar o 49 86 259 ΕΡ Ο 739 560/ΡΤ processamento das mensagens de divisão de chave tendo uma hora e data de mensagem mais velhas do que doze (12) horas (ou algum outro período de tempo específico) ou tendo uma hora e data de expiração que tenha já passado.
Implementação da caixa descodificadora
Num caso, as forças da lei empregam uma caixa descodificadora resistente a violação especial para interceptar e decifrar as comunicações de utilizadores monitorizados sob certas condições definidas e controladas. Um exemplo de uma caixa descodificadora e do seu fluxo de processo é mostrado na Fig. 20. A caixa descodificadora 200 é concebida para ser um dispositivo de confiança de uma concepção semelhante dentro do sistema de dispositivos confiáveis do presente invento e, portanto, pode reforçar várias condições a fim de evitar acções impróprias dos agentes das forças da lei. A caixa descodificadora 200 tem uma chave de assinatura de dispositivo privado incluída pelo fabricante e um certificado de chave de assinatura pública de fabricante 202 para a chave de assinatura pública que faz coincidir a chave de assinatura privada de dispositivo. Adicionalmente ao certificado de fabricante 202, a caixa descodificadora pode ter também um certificado 203 emitido por (ou em nome de) uma autoridade das forças da lei ou departamento de segurança de corporação a quem pertence a caixa descodificadora, atestando ou certificando perante um notário a ligação entre a caixa descodificadora e a autoridade de segurança ou das forças da lei, e atestando que a caixa descodificadora está sob a sua exclusiva posse e controlo. A caixa descodificadora 200 tem também a capacidade de gerar um par de chaves pública/privada, tal como a pastilha electrónica de utilizador regular do presente invento, para cifração e decifração de mensagens de administração e controlo para a caixa descodificadora. A caixa descodificadora 200 tem adicional mente a capacidade de armazenar a sua chave privada em segurança e de emitir a chave de cifração pública correspondente dentro de um certificado 201 assinado por si própria, com o seu certificado de dispositivo 202 assinado pelo fabricante anexo. Tendo esta capacidade de gerar (e utilizar) o par de chaves pública/privada permite aos agentes de garantia 206 de um utilizador escutado, com a apresentação pelos agentes das forças da lei ao centro de garantia principal de uma autorização para monitorizar as comunicações do utilizador, para enviar as divisões de chave 204 desse utilizador escutado para a caixa descodificadora cifrada, utilizando a chave de cifração pública da caixa descodificadora e possibilita que a caixa descodificadora decifre as divisões de chave, utilizando a sua chave de decifração privada. No entanto, de modo diferente de uma pastilha electrónica de utilizador 50 86 259 ΕΡ Ο 739 560/ΡΤ regular do presente invento, a qual decifra uma mensagem e faz retornar o resultado não cifrado para o utilizador, a caixa descodificadora nunca faz sair a chave privada do utilizador escutado para os agentes das forças da lei. Em vez disso, a caixa descodificadora armazena esta informação com segurança até ao fim do período de graça especificado na autorização e nas mensagens de divisão de chave, altura em que a caixa descodificadora apaga a informação permanentemente.
Por consequência, a fim de realizar as suas tarefas como um dispositivo de confiança e implementar as restrições de data e hora impostas pela autorização de escuta, a caixa descodificadora 200 deve também conter um relógio com data/hora certificado, calibrado de confiança 205. O fabricante da caixa descodificadora certifica e atesta a validade e a calibração do relógio 205 quando o fabricante emite um certificado de dispositivo 202 com a sua lista de propriedades de dispositivo conhecidas. Quando a caixa descodificadora 200 recebe dos agentes de garantia 207 as divisões de chave 204, contendo os limites de hora (baseados na autorização) antes ou depois dos quais a autorização não é válida, a caixa descodificadora 200 utiliza o seu temporizador de hora interno 205 para verificar que a autorização das forças da lei é ainda válida. Se a autorização não é ainda válida, a caixa descodificadora não deverá monitorizar ou decifrar as comunicações do utilizador escutado. Se a autorização (e qualquer período de graça aplicável) expirou, a chave privada de utilizador escutado é apagada e não será recriada novamente com essa autorização pela caixa descodificadora (a menos que uma nova autorização, tendo um novo período de tempo seja emitida). Deve ser notado que, embora o relógio de confiança 205 seja opcional para uma pastilha electrónica de utilizador regular do presente invento, é imprescindível para a caixa descodificadora 200, a fim de permitir que a caixa descodificadora implemente os limites de data e hora da autorização de escuta. No entanto, o utilizador da pastilha electrónica de utilizador regular pode auxiliar na implementação do limite de tempo através da manutenção da calibração do seu temporizador de relógio de pastilha electrónica. Se o relógio do utilizador não está calibrado, o MCH gerado pelo dispositivo do utilizador, durante as comunicações deverá conter um valor nulo no campo de atribuição de selo de tempo. Naquele caso, a caixa descodificadora ao interceptar a comunicação será capaz de implementar apenas a data de monitorização de paragem da autorização através da recusa de decifrar depois da expiração da autorização e dos períodos de graça. Então, a caixa descodificadora não pode implementar a data de monitorização de Início porque, enquanto a autorização ainda está válida, a autorização permite a decifração de todos os MCH 51 fifi
EP 0 739 560/PT submetidos com valores de atribuição de selo de tempo nulos mesmo que os mesmos sejam interceptados antes do período de autorização de data e hora de monitorização de início. Mas, se o relógio de utilizador está calibrado, a caixa descodificadora de implementação de lei pode e recusará decifrar todos os MCH, contendo um selo de tempo válida e de confiança para uma data e hora anterior à autorização de data e hora de monitorização de início. Mais de preferência, a caixa descodificadora deverá decifrar apenas comunicações com selos de tempo confiáveis durante os períodos de hora de garantia. É antecipado que esta imunidade adicionada a partir do potencial abuso dos períodos de tempo autorizados pelas forças da lei pode motivar que os utilizadores da pastilha electrónica deste invento a manter as suas pastilhas electrónicas num estado calibrado. Na verdade, quando o sistema é utilizado para cifrar grandes números de mensagens num sistema de armazenagem de dados, a implementação de períodos de tempo para uma autorização posterior ou ordem de verificação pode ser altamente desejável, porque, de outro modo, muitas mensagens fora do âmbito legal da autorização pode ficar sujeitas a inspecção.
Características de auditoria das forças da lei
Com um sistema de cifração garantido, existe uma preocupação de que os agentes das forças da lei possam ser facilmente subornados, a fim de obter chaves criptográficas que protejam dados de alto valor económico. Por exemplo, membros de uma associação criminosa bem consolidada podem ser capazes de roubar um conjunto de planos industriais valiosos de uma companhia particular, primeiro furando ilegalmente as comunicações da companhia, a fim de obter alguns cabeçalhos de mensagens e nomes de agentes de garantia, e depois através do suborno de um agente da polícia mal pago pedir uma autorização para uma investigação sobre drogas a fim de obter chave de decifração privada da companhia a partir dos agentes de garantia, e finalmente através da utilização da chave de decifração privada roubar os planos. Em virtude da cifração ser agora utilizada para comunicações seguras entre muitos computadores, já não é aceitável que as forças da lei façam escutas a um sistema de telecomunicações com salvaguardas mínimas. Um conjunto muito mais forte de salvaguardas é necessário a fim de trazer os procedimentos e controlos da polícia até ao nível das práticas modernas de segurança de computadores de corporações e evitar que este tipo de situações ocorram. 52 86 259 ΕΡ Ο 739 560/ΡΤ
Uma tal salvaguarda para o dispositivo de confiança é um contador interno para numerar cada cabeçalho de controlo de mensagem, contador que aumentará sequencialmente depois de cada acesso. O número de sequência de mensagem (MSN) pode ser colocado em cada cabeçalho de mensagem cifrado, a fim de que o mesmo não seja visível por um intruso. Isto pode ser feito através da cifração do número ou (1) com a chave de cifração pública do remetente, em conjunto com a cópia do remetente da chave de sessão de mensagem, (2) com a chave de cifração pública do agente de garantia de quer do remetente quer do destinatário, ou (3) de preferência, com, pelo menos, o remetente, receptor e os seus agentes de garantia, e possivelmente com todas as partes da comunidade de interesses. No entanto, o agente de garantia do remetente pode também, como uma questão de política, escolher permitir que o número de sequência seja exibido em claro, por questões de economia de espaço e do baixo risco de exposição. É crítico evitar duplicar os números de cabeçalhos de controlo de mensagem, e os intervalos na numeração devem ser evitados na medida do possível.
Uma outra característica de salvaguarda pode ser permitir ao utilizador incluir uma "linha de título" secreta opcional no cabeçalho de controlo de mensagem. Se um utilizador temer uma escuta ilegal com autorizações impróprias, o utilizador pode codificar um título curto, tal como o "Plan #123", a fim de o alertar e de alertar os outros para os conteúdos da mensagem. Em alternativa, um utilizador pode simplesmente conservar o seu próprio registo (através de um sistema de suporte lógico de correio) relacionando os números de sequência de mensagem assinada pelo dispositivo e os títulos assinados pelo utilizador. A fim de poupar espaço, a linha de título deve ter o comprimento zero se não for incluído qualquer título, como devia muitas vezes ser o caso.
Uma terceira protecção é adicionar à porção assinada do cabeçalho de controlo de mensagem uma compilação ou informação não válida dos conteúdos de mensagem, a fim de evitar que ou o utilizador ou as forças da lei reclamarem mais tarde que os conteúdos da mensagem decifrada eram diferentes dos realmente enviados. Isto é, por exemplo, o utilizador já não pode substituir mais tarde uma mensagem inofensiva por uma mensagem de negócio de drogas que tenha sido enviada anteriormente, nem pode corromper os agentes das forças da lei, substituindo mais tarde uma mensagem inofensiva ou de negócio de drogas pelos planos industriais valiosos que os agentes roubaram. 86 259 ΕΡ Ο 739 560/ΡΤ 53
Estas salvaguardas podem ser utilizadas como medidas de segurança adicionais. Primeiro, o número de sequência de mensagem gerada de dispositivo do remetente deve ser utilizado para seguir a mensagem, tanto pelo remetente como pelo receptor, bem como pelas forças da lei e pelo sistema de tribunal. Embora o acesso das forças da lei possa ser efectivamente difícil de controlar, especialmente durante a perseguição violenta de criminosos, e embora o sistema de tribunal nem sempre seja capaz de analisar cuidadosamente as exigências das forças da lei antes de emitir autorizações de escuta, diligência depois do facto poder ser exercido a fim de auditar os resultados de uma escuta, ou de qualquer escuta, de uma amostra aleatória de escutas, ou de escutas que de alguma maneira pareçam extraordinárias. O dispositivo de confiança dos agentes das forças da lei, a caixa descodificadora, é, por conseguinte, modificada para incluir um registo interno seguro dos números de sequência de mensagens e compilações de mensagens (e linhas de título, se existentes) das mensagens que a mesma controlou e permitiu que fossem lidas pelas forças da lei. A autorização electrónica, enviada para a caixa descodificadora pelos agentes de garantia do utilizador escutado, com as divisões de chave do utilizador, pode também incluir as chaves de cifração pública e assinatura do tribunal que emitiu a autorização. A caixa descodificadora é então capaz de responder a um pedido para imprimir o registo dos números de sequência de mensagem e linhas de título, possivelmente cifradas com a chave de um receptor autorizado adequadamente tal como o tribunal que emitiu a autorização.
Num exemplo, a caixa descodificadora não deve começará a decifrar as comunicações monitorizadas até que a mesma receba uma ordem específica do tribunal, que faz coincidir as divisões de chave recebidas dos agentes de garantia. Por exemplo, as mensagens de divisão de chave que são recebidas dos agentes de garantia e cifradas utilizando a chave de cifração pública da caixa decifradora podem ser melhoradas para incluir (a partir de cada agente de garantia) as chaves de cifração pública e de assinatura do tribunal que emitiu a autorização. Ou, os agentes de garantia podem referir nas suas mensagens de divisão de chave a data e número (se existir) da autorização, e a caixa descodificadora pode então receber do tribunal as chaves de cifração e de assinatura pública do tribunal, bem como o certificado de chave pública do tribunal, que foi anexo à autorização de escuta original. Por exemplo, a autorização do tribunal para os agentes de garantia pode ser melhorada para conduzir os dados seguintes, os quais são necessários para a mensagem de divisão de chave: 54 86 259 ΕΡ Ο 739 560/ΡΤ
Nome de centro de garantia principal ou número ID Número de certificado de utilizador controlado Nome do tribunal ou número ID Número de autorização (se algum)
Data e hora da autorização Data e hora de início de monitorização Data e hora de paragem de monitorização Número máximo de mensagens (opcional) [Assinatura do Juiz]
Certificado do Juiz
Certificado Certificador de Juiz (por exemplo, tribunal, etc.)
Os agentes de garantia podem então "certificar de novo" as chaves de cifração pública e assinatura do tribunal para a caixa descodificadora, fazendo com que as mensagens de divisão de chave cifradas dos agentes de garantia para a caixa descodificadora incluam a seguinte informação adicional, a qual deve estar presente em cada divisão de chave de cada agente de garantia:
Nome de centro de garantia principal ou número de ID Número de certificado de utilizador monitorizado
Nome de agente de garantia ou número de ID (que envia esta mensagem de divisão de chave)
Nome de tribunal ou número de ID Chave de cifração pública do tribunal Chave de assinatura pública do tribunal Número de autorização (se existir)
Data e hora da autorização Número máximo de mensagens (opcional) 55 06 259 ΕΡ 0 739 560/ΡΤ
Assinatura de agente de garantia [Certificado de agente de garantia] A caixa descodificadora recebe então a certeza de que todas as mensagens de divisão de chave vêm do mesmo juiz e da mesma autorização. O facto da caixa descodificadora ter também as chaves de assinatura e de cifração pública do juiz permite que o juiz exija e receba (confidencialmente) o registo de todos os números de sequência de mensagens e linhas de título de mensagens interceptadas e decifradas pela caixa descodificadora, durante o período de escuta, como uma auditoria após a escuta para salvaguardar contra condutas , injustificadas, ilegais ou corruptas dos agentes das forças da lei. Adicionalmente, a caixa descodificadora não limpa, apaga, ou reutiliza qualquer memória atribuída ao registo de mensagem controlado até que a caixa descodificadora receba uma ordem separada do juiz ou tribunal, verificada em relação à chave de assinatura pública anteriormente recebida, declarando que a caixa descodificadora pode fazer isso. Uma tal ordem será emitida quer porque o tribunal já tinha recebido da caixa descodificadora o registo de mensagem monitorizado que o mesmo tinha previamente exigido, quer porque o tribunal decidiu que não era necessária neste caso qualquer auditoria. Se a área de armazenagem de memória de registo de mensagem controlado ficar cheia, a caixa descodificadora não decifrará mais quaisquer mensagens até que o registo seja enviado para o juiz ou tribunal e uma ordem assinada pelo tribunal seja recebida, permitindo que a caixa descodificadora apague o registo de mensagem monitorizado. As forças da lei podem continuar a interceptar novas mensagens durante a limpeza do registo de mensagem controlado, embora as novas mensagens não devam ser decifradas até que o registo de mensagem completo seja limpo para auditoria. A caixa descodificadora terá também uma característica de alerta das forças da lei que o registo de mensagem monitorizado se está a aproximar da capacidade, de modo que elas possam pedir que o registo de auditoria de mensagem seja carregado a fim de que a caixa descodificadora não cesse a decifração. Estas transacções e comunicações podem ser completamente automatizadas e quase instantâneas.
Cada entrada no registo de auditoria pode conter, adicionalmente a uma compilação da mensagem, um segunda compilação que é o produto de (a) a compilação de mensagem mais (b) o texto completo da entrada de registo prévia encadeado em conjunto e novamente compilado. Isto pode evitar que qualquer 56 86 259 ΕΡ Ο 739 560/ΡΤ pessoal de tribunal desonesto adicione, apague ou torne a sequenciar as entradas no registo. Este conceito é explicado nas patentes U.S. n°s. 5.136.646 e 5.136.647.
Como uma acção seguinte, o tribunal pode exigir mais tarde que as forças da lei submetam os cabeçalhos de mensagem e o conteúdo completo das compilações de mensagem ao registo de auditoria que o tribunal recebeu. Também, na sua autorização e escuta, o tribunal pode artificial mente limitar para menos do que a capacidade de registo de mensagem completa o número de mensagens monitorizadas que podem ser decifradas pela caixa descodificadora antes que o registo de mensagem monitorizado e os cabeçalhos de mensagem devam ser auditados. Embora este tipo de limite não deva ter efeito na capacidade total das forças da lei para investigar, porque o carregamento do registo no tribunal para auditar é quase instantâneo, pode alertar o tribunal para circunstâncias extraordinárias. Em casos específicos que exigem controlos que são mais fortes do que mero envio do registo de mensagens monitorizado para o tribunal, o tribunal pode limitar as forças da lei para menos do que a capacidade de registo de mensagens completo, antes que as forças da lei devam procurar uma autorização adicional para controlar comunicações adicionais.
Assim, se (1) tanto o remetente como o receptor seguirem os números de sequência das mensagens que eles enviam e recebem, e quer linhas de título associadas aos cabeçalhos de controlo de mensagem quer o registo das mensagens nos seus sistemas de suporte lógico locais, (2) tanto as forças da lei como o tribunal retêm um registo completo de cada mensagem decifrada pelas forças da lei, e (3) cada cabeçalho de mensagem inclui uma compilação da mensagem, a fim de evitar que qualquer parte possa mais tarde alterar a mensagem para cobrir as suas acções, então uma auditoria credível após escuta pode determinar se pode ter havido qualquer abuso ou acção de corrupção pela agência das forças da lei. Embora este sistema ainda não possa ser evitar, à priori, o cenário de plano roubado mencionado acima, o conhecimento pela associação criminosa de que as suas acções podem ser completamente auditadas por tanto pelo tribunal como pelos utilizadores sujeitos, pode fornecer uma verificação valiosa de acções impróprias da polícia. Pode também ser feita uma questão de regulação para que a agência da força da lei grave e submeta ao tribunal todas as mensagens interceptadas com uma autorização e permite às partes escutadas requisitar uma auditoria à escuta, particularmente, quando o sujeito está associado a uma empresa de negócios e não são feitas quaisquer acusações criminais com base nessa escuta.
86 259 ΕΡ Ο 739 560/ΡΤ
Dados de corrente orientada
Em comunicações que envolvem dados de corrente orientada, tal como uma chamada telefónica, na qual cada comunicação consiste numa corrente de vários pacotes de mensagens de dois ou mais utilizadores, é impossível para o dispositivo remetente informar não validamente e assinar toda a mensagem como parte do MCH. Embora seja possível enviar um MCH com cada pacote de uma comunicação, fazer isto deve ser muito caro em termos de tempo de processamento e de largura de banda de rede. Portanto, o MCH deve ser portanto transmitido apenas uma vez, na altura do estabelecimento da chamada. Uma maneira preferida de tratar correntes contínuas de dados cifrados é nomear o utilizador que chama como o "remetente" e negociar o MCH no inicio da comunicação, como anteriormente, incluindo o número de sequência de mensagem (MSN) e a informação não válida do primeiro pacote (se existir) assinada pelo dispositivo. Então, o dispositivo do remetente pode gerar uma série de números de sequência de pacote única (PSN), cuja sequência começa com zero no início de cada comunicação. Para todos os pacotes subsequentes, o dispositivo necessita apenas de dar informação não válida e assinar o pacote particular, e incluir (e assinar) a informação não válida, o MSN (a mesma para toda a mensagem) e o PSN para o pacote. Quem recebe a chamada deverá executar acções semelhantes para cada pacote que ele manda, referindo o MSN de quem chama para a comunicação, numerando sequencialmente os seus próprios pacotes, começando no zero, e tendo o dispositivo chamado assinado um grupo, que consiste na informação não válida de pacote, o MSN de quem chama e o PSN de quem recebe a chamada, formando portanto um "cabeçalho de controlo de pacote" (PCH). Os dispositivos podem opcionalmente incluir a hora real como um início a partir da hora de início da comunicação (em segundos ou milisegundos), a qual está já presente nas versões descritas anteriormente do MCH. Isto pode permitir que a chamada seja passada de novo mais realisticamente. A fim de distinguir adicionalmente os pacotes de quem chama e de quem recebe a chamada depois da comunicação, será também desejável incluir um código de partes de chamada (CPC) com um esquema de codificação simples atribuindo números às partes da comunicação, tal como quem chama = 0, quem recebe a chamada = 1, e quaisquer partes adicionais para a mesma sessão cifrada, recebendo números mais altos. Ou podem ser utilizados, no lugar do CPC, um único número de identificação, tal como o número de série de dispositivo, o número
86 259 ΕΡ Ο 739 560/ΡΤ 58 de série de dispositivo mais o número de ID do fabricante do dispositivo, ou a informação não válida do anterior,.
Estes processos podem também ser generalizados como um processo para a geração de chave de sessão com múltiplas partes. Por exemplo, quem chama pode gerar uma chave de sessão e utilizar a mesma chave para iniciar chamadas com várias chamadas simultaneamente, utilizando o transporte de chave RSA. Existirá então um MCH separado para cada parte adicionada depois das duas primeiras partes (quem chama e quem é chamado). O dispositivo que chama pode tratar a chamada com partes múltiplas como chamadas separadas ou como uma única chamada tendo a mesma chave de sessão, mas tendo múltiplos CPC. Cada um que recebe a chamada deve então ser responsável por utilizar o MSN de quem chama e por manter os seus próprios CPC e PSN. Em alternativa, assumindo a utilização dos processos de geração de chave de sessão de duas partes convencionais (tal como os processos de Diffie-Hellman), as chamadas em conferência podem existir, nas quais uma parte central (por exemplo, um operador de sistema) coloca todas as chamadas e realiza a decifração em tempo real e nova cifração dos pacotes de cada parte para todas as outras. A parte central pode também ser o indivíduo que endereça de novo para o seguinte a receber a chamada, caso em que os pacotes de que recebe a chamada deveriam ser decifrados pelo dispositivo do indivíduo e então cifrado de novo utilizando a(s) chave(s) de sessão que quem recebe a chamada está a utilizar para comunicar com a outra parte (ou partes). Ver também B. Schneier, Applied Crvptoaraphv. J. Wiley 1994, a págs. 276, no que se refere à utilização de Diffie-Hellman com três ou mais partes.
Um cabeçalho de controlo de pacote (PCH) pode ser formulado como segue: MSN de quem origina a chamada Código de partes de chamada de utilizador (CPC) (quem chama = 0, etc.) Número de sequência de pacote de utilizador (PSN)
Hora de início a partir do estabelecimento da chamada (mseg)
Informação não válida (deste pacote) [Assinatura de dispositivo]
Pode ser preferível não enviar um PCH com cada pacote de comunicações, devido resultar em sobreposição pesada em alguns sistemas que utilizam pacotes curtos, mas em vez disso enviar o PCH apenas periodicamente. Isto é semelhante
86 259 ΕΡ Ο 739 560/ΡΤ 59 à técnica conhecida como "janelas deslizantes" em comunicações em rede, em que a sequência de pacotes e novas entradas não são realizadas para cada pacote mas apenas para uma pluralidade de pacotes. Nurriialrnenle tais sistemas ajustam dinamicamente a "janela", ou o número dos pacotes que são enviados entre verificações de erro, com base no ruído de linha, isto é fazendo a janela grande para uma linha limpa, mas fazendo a mesma pequena para uma linha ruidosa que está a causar muitas novas entradas de erro. Se ocorrerem frequentemente erros, uma janela pequena deve exigir do utilizador que torne a enviar apenas uma pequena quantidade de dados; se os erros são raros, a verificação pode ser realizada menos frequentemente, não obstante com um alto custo para tornar a enviar dados perdidos no caso de um erro. Os cabeçalhos de controlo de pacote podem ser directamente integrados num esquema de janela deslizante de um sistema de comunicações, fornecendo portanto a capacidade desejada para auditar as acções das forças da lei para o nível de pacote, ao mesmo tempo que permite também passagem através do sistema máximas numa rede de comunicações moderna.
Para reforçar adicionalmente a capacidade de auditoria do processo de escuta, é vantajoso marcar positivamente o fim de uma sessão de comunicações com qualquer pacote especial. Este pacote pode ser enviado automaticamente por cada dispositivo para os outros antes de desligar, não reconhecido para os utilizadores, a fim de evitar que quer os utilizadores quer os agentes das forças da lei venham mais tarde reclamar que a conversação terminou ou não terminou, quando o oposto de facto ocorreu. Isto pode ser conseguido dando instruções a cada dispositivo para aceitar uma entrada "quer desligar agora" do seu utilizador humano, após o que o dispositivo deve enviar para fora um pacote "preparar para desligar", o qual deve então estimular o(s) outro(s) dispositivo(s) para fazer o mesmo. O(s) dispositivo(s) devem terminar as suas correntes de dados com um pacote "final" que não contém dados adicionais, mas que inclui, de preferência, os totais de todos os pacotes enviados e recebidos, a duração da chamada, etc.
Dispositivo de atribuição de selo de tempo
Uma outra característica deste invento na sua concretização preferida, como explicado acima, no que se refere à caixa descodificadora, é a utilização de um dispositivo de atribuição de selo de tempo resistente a violação e de confiança, que auto-certifica que o mesmo pode emitir (ou afixar) digitalmente selos de tempo assinados (ou estruturas de dados, contendo tais selos de tempo), que podem ser 86 259 ΕΡ Ο 739 560/ΡΤ 60
merecedoras de confiança para terceiras partes. Tais dispositivos de atribuição de selo de tempo são descritos nas U.S. n°s. 5.001.752 e 5.136.643, de Addison M. Fisher. Na sua concretização preferida, mostrada na Fig. 21, o dispositivo de atribuição de selo de tempo 210 (ou o subsistema) pode ser calibrado e regulado para funcionar apenas com uma autoridade de confiança, tal como o fabricante ou quem o fabricante confia, da mesma maneira que uma máquina de franquear apenas pode ser regulada pela estação de correios local dos Correios dos Estados Unidos e é a partir de então de confiança para o público e para o sistema postal para distribuir selos postais apenas até à quantia previamente paga. Uma vez calibrado, o dispositivo de atribuição de selo de tempo 210 (ou subsistema) responderá a uma instrução de "regulação de tempo" 211 (ou recalibração) apenas se a instrução for assinada ou pelo próprio fabricante ou por uma entidade que tenha afixado o certificado 212 do fabricante, ou em quem o fabricante confia, atestando que a entidade é de confiança para regular e calibrar o dispositivo de atribuição de selo de tempo (ou subsistema) do dispositivo central. A operação da instrução de regulação de tempo deve provavelmente precisar de ser realizada em pessoa com a autoridade de regulação de tempo a tomar momentaneamente posse física do dispositivo e apagando imediatamente a instrução de regulação de tempo 211, a fim de evitar a possibilidade de um dono de dispositivo captar a instrução e tornar a passar a mesma mais tarde para fazer "retroceder no tempo" um relógio do dispositivo.
Uma vez calibrado e enquanto não for mexido, o dispositivo de atribuição de selo de tempo 210 afixará selos de tempo 213 ou dados de selos de tempo completos nos campos de dados estruturados, com base no seu mecanismo de relógio interno, assinando 214 as estruturas de dados resultantes com a sua chave de dispositivo privada e fornecendo o seu certificado de fabricante 215. se o dispositivo central perder a alimentação, for violado ou receber uma instrução para se desactivar a si próprio, o dispositivo de atribuição de selo de tempo cessará de emitir selos de tempo. Nesse caso, a fim de evitar danificar outras funções possivelmente úteis que não precisem como um elemento absoluto dos selos de tempo confiáveis, o dispositivo de atribuição de selo de tempo utilizará uma convenção, tal como o preenchimento do campo de selo de tempo com um valor "nulo" previamente acordado, tal como todos os zeros binários ou os uns binários (ou um convenção equivalente), quando um campo de dados estruturado pede que seja incluído um selo de tempo. No entanto, quando um campo de dados estruturado ou o dispositivo central requerem que seja emitido um selo de tempo real, tal como no caso de uma caixa descodificadora das forças da lei, se o
86 259 ΕΡ Ο 739 560/ΡΤ 61 dispositivo de atribuição de selo de tempo cessou de emitir selos de tempo, as funções do dispositivo central que exigem selos de tempo não operam; no caso da caixa descodiflcadora, a caixa recusará decifrar as comunicações interceptadas. A fim de evitar ou minimizar a ocorrência da situação de perda de alimentação do dispositivo central, cada dispositivo de atribuição de selo de tempo de confiança deve, de preferência, estar equipado com a sua própria bateria de longa duração separada 216, apenas para utilização do relógio, qualquer indicador de aviso de "bateria baixa" para evitar a perda de alimentação do dispositivo de atribuição de selo de tempo antes de uma troca de bateria e alguns meios para reter uma carga eléctrica adequada (tal como um condensador de armazenamento, um segundo compartimento de bateria ou uma unidade de alimentação externa opcional) durante as operações de troca de bateria.
Para cada selo de tempo emitido pelo dispositivo de atribuição de selo de tempo, pode existir um certificado de dispositivo de atribuição de selo de tempo emitido pelo fabricante (ou outra autoridade de regulação de tempo) atestando a qualidade e confiança do relógio de atribuição de selo de tempo, a data na qual ele foi regulado a última vez, bem como o seu desvio de tempo esperado. Quando um utilizador de recepção recebe uma estrutura de dados que foi digitalmente assinada pelo dispositivo central, o receptor sabe que, se o campo de atribuição de selo de tempo está completado com um valor válido, o certificado e a assinatura de dispositivo certificam que o tempo estava correcto quando a estrutura de dados foi criada, assinada e emitida. Esta certificação é apoiada (1) na exactidão da autoridade que mais recentemente calibrou o relógio da atribuição de selo de tempo, (2) nas tolerâncias de desvio do relógio, indicadas pelo fabricante no certificado de dispositivo, e (3) na capacidade do relógio de se desactivar a si próprio quando de violação ou de perda de energia. O receptor sabe ainda que, se o campo de atribuição de selo de tempo contém um valor "nulo", então o relógio de atribuição de selo de tempo não estava no estado de calibração de confiança na altura em que o dispositivo criou, assinou e emitiu a estrutura de dados. Esta informação respeitante às propriedades confiáveis do dispositivo de atribuição de selo de tempo e do seu mecanismo de relógio interno, pode ser, de preferência, codificada directamente dentro do certificado de dispositivo, utilizando um esquema de codificação de atributo de valor adequado. No entanto, esta informação pode também estar implícita do nome do fabricante e do tipo de dispositivo, o que pode ser publicado pelo fabricante numa certificação de especificação e desempenho, como parte de uma "declaração de política" apresentada publicamente na altura em que o certificado dc dispositivo c emitido. 62 86 259 ΕΡ Ο 739 560/ΡΤ
Tais selos de tempo podem também ser emitidos pelo dispositivo, como parte de outras operações de tratamento de mensagens para além da criação e descodificação de MCH. Estes selos de lempo podem ser apensos à assinatura pessoal do utilizador de dispositivo quando o utilizador assina outro documento ou transação utilizando a sua chave de assinatura pessoal, a qual está confinada em segurança dentro do dispositivo. O dispositivo deve assinar ou co-assinar o elemento de selo de tempo da assinatura do utilizador, ou pode em alternativa assinar sobre o bloco de assinatura inteiro do utilizador (o qual continha o selo de tempo, também assinado pelo utilizador, em conjunto com a compilação de mensagem de resultado de informação não válida do documento). O dispositivo pode então fornecer o seu certificado a fim de tornar o selo de tempo crível e de confiança para uma terceira parte, que conhece a chave pública do fabricante.
Actualizacão confiáveis, substituição e repetição de chave O dispositivo de confiança resistente a violação pode conter uma chave pública do fabricante incluída, uma área de memória não volátil protegida e uma unidade de processador central segura (CPU) e pode actualizar ou suplementar de uma maneira de confiança quaisquer rotinas de suporte lógico inalterável incluídas pelo fabricante. O dispositivo de confiança faz a actualização ou suplementa pela aceitação como entrada de um corpo de dados, contendo códigos de suporte lógico inalterável adicionais ou novos, que são adequados para esse tipo de dispositivo e são assinados digitalmente com a assinatura do fabricante, assinatura que assegura ao dispositivo que o código de suporte lógico inalterável novo foi desenvolvido, testado e aprovado pelo fabricante e que o dispositivo deve, por conseguinte, quer (a) sobrepor o código de suporte lógico inalterável novo a uma ou mais rotinas de suporte lógico inalterável incluídas quer (b) adicionar o código de suporte lógico inalterável novo como uma ou mais rotinas novas a uma área normalmente não utilizada da memória protegida. Na concretização preferida, a memória protegida deve ser do tipo “FLASH”, a qual pode reter a sua informação indefinidamente, quanto a alimentação é desligada, mas também pode ser apagada pelo dispositivo (não obstante, relativamente devagar), e utilizada de novo se desejado. A memória protegida pode também incluir qualquer área de armazenagem de dados (tal como uma unidade de disco), sendo ou não resistente a violação, na qual o código a ser actualizado ou acrescentado pode ser armazenado numa forma cifrada, para a qual a chave de decifração é conhecida apenas pelo dispositivo de confiança. Pela armazenagem dos programas numa forma cifrada, o dispositivo ovita efectivamente que eles sejam modificados por 63 86 259 ΕΡ Ο 739 560/ΡΤ alguém sem conhecimento da chave de decifração. Quando o dispositivo recebe um tal corpo assinado do novo código de suporte lógico inalterável (ou suporte lógico), o utilizador insere o código em conjunto com a assinatura do fabricante e emite uma instrução de "actualizar suporte lógico inalterável de processo" para o dispositivo. O dispositivo verifica então a assinatura de fabricante utilizando a chave de assinatura pública do fabricante, a qual foi incluída no dispositivo durante o fabrico. Se a assinatura do fabricante se verifica, o código é aceite e o dispositivo realiza a actualização desejada. O processo de uma actualização de confiança no suporte lógico inalterável de um dispositivo de confiança como descrito acima pode ser adicionalmente aumentado para acomodar terceiras partes autorizadas que desejem actualizar rotinas de suporte lógico inalterável, que pertencem a funções de dispositivo relevantes para as terceiras partes, incluindo funções tais como o sistema de garantia de chave presente, as quais podem ser em grande parte concebidas e administradas por um centro de garantia principal bancário independentemente do fabricante do dispositivo de confiança. Num exemplo da actualização de terceira parte, o fabricante pode assinar um certificado de actualização de suporte lógico inalterável contendo uma chave pública do fornecedor do suporte lógico da terceira parte e emiti-lo para a terceira parte. A terceira parte pode então desenvolver, testar e aprovar rotinas de suporte lógico adicionais ou de substituição, assiná-las com a chave de assinatura privada da terceira parte, e anexar o seu certificado de actualização a partir do fabricante. Depois de receber uma tal actualização, o utilizador deve carregar ambas as rotinas de código assinadas e o certificado de actualização do fabricante dentro do dispositivo e então emitir uma instrução de "actualizar suporte lógico inalterável da terceira parte de processo". O dispositivo deve então verificar a assinatura da terceira parte nas novas rotinas de código contrapondo o certificado de actualização de fabricante e verificar então o certificado de actualização contrapondo a chave de assinatura pública do fabricante que foi incluída no dispositivo durante o fabrico. Se ambas as assinaturas se verificam, a actualização é aceite e o dispositivo realiza a actualização desejada.
Além da aceitação das instruções para actualizar ou suplementar as rotinas de suporte lógico inalterável de dispositivo, um dispositivo de confiança resistente a violação pode também aceitar instruções para substituir ou acrescentar chaves públicas e "instruções" que foram incluídas durante o fabrico. Como explicado anteriormente, um dispositivo de confiança pode ter chaves públicas, para além das do fabricante, incluídas durante o fabrico do dispositivo. Tais chaves públicas de
86 259 ΕΡ Ο 739 560/ΡΤ 64 "instruções” podem incluir as chaves de um ou mais centros de garantia principais, como descrito no presente invento. Estas chaves incluídas, incluindo as chaves do fabricante ou de outras terceiras partes confiáveis, podem ser utilizadas para verificar vários certificados, tais como certificados de garantia, certificados de dispositivo, certificados de actualização, certificados de instrução de regulação de tempo e outros que podem ser apresentados ao dispositivo para o mesmo actuar sobre os mesmos. Para além de contar apenas com as chaves públicas, incluídas durante o fabrico, o dispositivo pode também aceitar instruções externas para incluir novas chaves públicas ou para substituir as existentes. A fim de um dispositivo aceitar e armazenar numa área não pública a chave de assinatura pública de uma terceira parte de confiança, o fabricante deverá incluir a nova chave pública num pacote de dados de instrução assinado (ou certificado) assinado pelo fabricante, dando instruções ao dispositivo para descartar o certificado incluído e armazenar dentro a chave de instruções pública indicada. O pacote especial pode também dar instruções ao dispositivo para que tipos de transacções a nova chave é de confiança (por exemplo, para utilizar numa aplicação de garantia de chave, aplicação de aluguer de viaturas, aplicação de dados médicos, ou outra utilização). Quando da recepção de um tal pacote de dados de chave pública do fabricante, o dispositivo deve primeiro verificar a assinatura do fabricante e depois aceitar e armazenar a nova chave pública em conjunto com a restrição sobre a utilização da chave pública. O fabricante pode também indicar na altura de inserir uma chave de instruções pública de terceira parte, ou durante o fabrico ou mais tarde como parte de um pacote de dados de instruções, que uma das transações para a qual a chave de terceira parte é aprovada é a substituição da chave de verificação de assinatura pública subjacente própria do fabricante. Embora uma tal substituição da chave de assinatura pública própria de fabricante não devesse quase nunca ser exigida, existe uma possibilidade de que a chave de assinatura privada correspondente do fabricante (para emitir certificados de dispositivo e outras instruções para o dispositivo) possa ser comprometida através de roubo. O roubo da chave de assinatura privada de fabricante deve permitir ao ladrão emitir aparentemente instruções válidas, para aprovar novos centros de garantia (de confiança dúbia) e para aprovar novas autoridades de regulação de tempo. Em alternativa, e mais provável, a chave de assinatura privada de fabricante pode simplesmente ser perdida ou destruída, evitando assim a emissão de quaisquer instruções válidas adicionais. Qualquer um destes acontecimentos devem ser classificados como um "desastre" em termos de sistemas de computador e podem resultar em todos os 65 ΕΡ Ο 739 560/ΡΤ dispositivos do fabricante, tendo que ser chamados de novo. No entanto, através do presente invento, o custo de uma tal nova chamada pode ser evitado ou mitigado, permitindo que uma lerceira parte de confiança substitua a chave de assinatura comprometida do fabricante. Assumindo que o fabricante tinha já incluído as chaves de instruções de uma ou mais terceiras partes dentro do dispositivo, ou durante o fabrico, ou mais tarde utilizando um pacote de dados de instruções, e tinha incluído a substituição da sua própria chave pública entre as transações que a chave de instruções pública da terceira parte pode aprovar, o fabricante pode então voltar para essa terceira parte de confiança e requerer que ela emita um pacote de dados de instrução para todos os dispositivos do fabricante, autorizando a substituição da chave de assinatura pública do fabricante, poupando assim a ela própria e aos seus utilizadores o enorme custo de substituir fisicamente todos os dispositivos físicos. Devido a todos os certificados de dispositivo emitidos pelo fabricante deverem também ser substituídos, isto pode ser conseguido tendo cada dispositivo emitido um pedido de certificado para a chave de assinatura de dispositivo pública própria do dispositivo. Se a chave privada de fabricante for perdida ou destruída, e não comprometida, então todas as assinaturas anteriores devem ser ainda válidas e um utilizador deve precisar apenas de apresentar o seu certificado de dispositivo antigo a fim de ter um novo certificado de dispositivo, emitido para a mesma informação, assinado pela nova chave de assinatura do fabricante. O fabricante deve fazer então retornar novos certificados de dispositivo (mais provavelmente através de uma transação em tempo real ou de correio electrónico). Embora isto seja ainda caro, será muito mais barato e menos prejudicial para a reputação do fabricante do que a substituição física extensa de todos os dispositivos confiáveis do fabricante no campo. A inclusão dentro de um dispositivo de confiança de um mecanismo para substituir uma chave pública de fabricante ou qualquer outra chave de instruções pública de confiança pode mitigar alguns dos riscos de segurança sistemáticos que estão postos pela utilização das chaves públicas de raiz de sistema geral. Isto deverá permitir uma maior confiança nos modelos de confiança puramente hierárquicos, os quais geralmente permitem circuitos de certificação mais simples e mais curtos, exigindo menos certificados, menos esforço para determinar quais certificados se devem utilizar e menos tempo de computador para verificar as assinaturas.
86 259 ΕΡ Ο 739 560/ΡΤ 66
Repetição de chave controlada de dono
Como anteriormente descrito, o utilizador também tem a opção de repetir a chave do seu dispositivo como para o seu par de chaves de cifração de utilizador em qualquer altura depois do fabrico. O utilizador faz isto depois de emitir uma instrução de suporte lógico inalterável para o dispositivo de confiança para realizar os passos particulares do processo de garantia de chave, isto é, para gerar um par de chaves de cifração pública e privada nova, envia as divisões de chave para os agentes de garantia e recebe por fim um novo certificado de garantia do centro de garantia principal. No entanto, é também desejável permitir que um empregador de utilizador ou patrocinador (ou dono, se o utilizador é outro dispositivo ou processo) controle os processos de chave ou de repetição de chave de modo (a) a assegurar que o utilizador seleccione os agentes de garantia que o empregador determinar aceitáveis e (b) a assegurar que o empregador, como o verdadeiro dono do dispositivo, deverá permanecer conhecido dos agentes de garantia seleccionados e por isso será capaz de requerer as divisões de chave do utilizador a partir dos agentes de garantia sem ter de primeiro obter uma autorização ou uma autorização do tribunal. O empregador pode pedir o acesso à chaves de um dispositivo particular por qualquer número de razões, tal como administrar uma vigilância interna ou para recuperar dados de propriedade cifrados depois do dispositivo aplicável ter sido perdido, roubado ou destruído. O empregador pode também necessitar de repetir a chave do dispositivo por qualquer de um número de razões, tal como para um dispositivo cujas chaves de assinatura ou cifração anteriores foram comprometidas ou limpas, para um dispositivo que foi dado a um empregado diferente, ou para um dispositivo cuja organização dona repete a chave de todos os dispositivos criptográficos em intervalos periódicos como uma questão de plano de acção.
Na concretização preferida, o dispositivo de confiança pode ser previamente ajustado pelo fabricante de modo que ele não inicie a geração de chave e processo de garantia, a não ser que o dispositivo receba primeiro um certificado do dono para o dispositivo 220, tal como um mostrado na Fig. 22, contendo o número de série permanente 221 do dispositivo particular e assinado 225 pelo fabricante. O certificado de dono 220, emitido na altura da compra pelo fabricante para a empresa compradora do dispositivo, também contém o nome 222 da empresa, o número de identificação único 223 da empresa (tal como o número de identificação de empregador de serviço de benefício Interno (EIN) ou o número de Dun & Bradstreet (DUNS) ) e a chave de verificação de assinatura pública 224 da
86 259
EP 0 739 560/PT 67 empresa, a qual corresponde à chave de assinatura privada guardada pela empresa e a qual será utilizada para verificar a repetição de chave ou outras instruções emitidas pela empresa para o dispositivo. Subsequentemente à recepção desta informação, o dispositivo deve responder apenas à repetição de chave ou outras instruções que estão assinadas utilizando a chave de assinatura privada da empresa dona correspondente à chave pública contida no certificado do dono do dispositivo.
Referindo agora a Fig. 23, quando o empregador (o dono do dispositivo) deseja repetir a chave do dispositivo 230, o empregador emite uma instrução assinada 231 para o dispositivo 230, incluindo (1) o número de série 232 do dispositivo, o número de identificação de dono único 233, (2) os nomes dos agentes de garantia 235 e o centro de garantia principal 234, (3) a data e hora da instrução de repetir a chave, (4) a data e hora do termo da instrução de repetir a chave 236 e (5) o número de série único de instrução de repetir a chave 237 e assina a instrução utilizando a chave de assinatura privada de empregador 238. Depois de receber um certificado de dono válido 239 e uma instrução de repetir a chave válida 231, a pastilha electrónica dentro do dispositivo de confiança 230 verifica primeiro a assinatura de fabricante no certificado de dono 239 e a assinatura de empregador na instrução de repetir a chave 231. O dispositivo de confiança completa então a geração de chave e o processo de garantia, como antes, incluindo o número de identificação único de dono 233 dentro de cada pacote de partilha de garantia, e envia os pacotes de partilha apenas para os agentes de garantia 235 indicados pelo empregador na instrução de repetir a chave 231. A repetição subsequente destas instruções (a qual pode ser emitida electronicamente) pode ser limitada ao indicar o dispositivo, a fim do dispositivo reter em armazenagem não volátil os números de série das últimas várias instruções de repetição da chave que o mesmo recebeu e recusar executar as instruções de novo. Assumindo que o relógio de tempo do dispositivo é mantido em bom estado, a repetição subsequente das instruções de repetição da chave pode também ser limitado simplesmente através de instrução ao relógio de tempo do dispositivo para cumprir a data e hora de termo da instrução. Numa concretização preferida, um dispositivo cujo relógio não está calibrado deve recusar processar uma instrução de repetição da chave que tenha uma data/hora de termo não nulas, mas deve seguir se a data/hora de termo for deixada nula.
Depois da recepção de um dispositivo utilizador os pacotes de partilha de divisão de chave (ou repetição de chave), contendo um único número de
86 25Θ ΕΡ Ο 739 560/ΡΤ 68 identificação de dono, os agentes de garantia e o centro de garantia principal devem gravar o número de identificação único nas suas respectivas bases de dados e devem, subsequenLemenle, honrar os pedidos do dono para aceder à chave de cifração privada. Numa concretização preferida, os agentes de garantia e centro de garantia devem cada um deles exigir que um pacote de partilha de divisão de chave que indica um único número de identificação de dono deve ser também acompanhado pelo respectivo certificado de dono de dispositivo assinado pelo fabricante. Este certificado de dono de dispositivo deve permitir os agentes de garantia e o centro de garantia principal de actuarem nas mensagens de pedido de chave, assinadas com a chave de assinatura privada de dono, correspondente à chave pública do dono no certificado do dono de dispositivo.
Numa outra concretização, ao dispositivo de confiança pode ser permitido a aceitar a repetição de chave, a repetição de garantia, a transferência de propriedade ou outras instruções do dono do dispositivo sem ter de utilizar um certificado de dono e dispositivo separado. O requisito de ter de utilizar um certificado do dono separado para instruções para o dispositivo é um ónus administrativo, porque o dono tem de manter uma base de dados de certificados para todos os seus dispositivos e localizar o certificado apropriado cada vez que ele queira repetir a chave de um dispositivo ou enviar ao dispositivo algumas outras instruções. Uma abordagem melhor, como mostrado na fig. 26, é o fabricante emitir para o dono um certificado único para a chave de instruções pública do dono para uma dada família de dispositivos, deixar o vendedor instalar a sua chave de verificação de instruções pública 261 dentro do dispositivo 260, quando o dispositivo 260 é vendido, e depois instituir um sistema apoiado na armazenagem interna das chaves. Depois da venda inicial do dispositivo pelo seu fabricante para um dono, o dispositivo 260 deverá primeiro verificar a validade do certificado de fabricante 262 do dono, utilizando a chave de instruções pública 263 do fabricante, que foi incluída dentro do dispositivo pelo fabricante. Se a área de chave de instruções pública 264 do dono, dentro do dispositivo está em branco, o dispositivo deverá copiar a chave de instruções pública 261 do dono a partir do certificado de fabricante 262 do dono para dentro da área de chave de instruções pública 264 do dono do dispositivo. Se uma chave de instruções pública de dono já exista no dispositivo e é diferente da do dono, que tenta iniciar o dispositivo, o dispositivo assume que o fabricante vendeu o dispositivo a outra entidade. Porque cada dispositivo deverá ter, pelo menos, um dono primário, a propriedade do dispositivo será determinada pela presença ou falta de uma chave de instruções pública 261
86 259 ΕΡ Ο 739 560/ΡΤ 69 do dono dentro do dispositivo 260, em vez do (ou adicionalmente ao) conceito anterior de um certificado do dono.
Se nenhuma chave de instruções pública de dono está instalada, o dispositivo é considerado como sendo um dispositivo de consumidor de utilizador único que não está limitado com vista à repetição de chave ou à transferência de propriedade do dispositivo; como tal, o dispositivo deverá considerar a não existência de uma chave do dono instalada, como um sinal para obedecer às instruções do utilizador sem invocar a repetição de chave, a repetição de garantia e as regras de transferência de propriedade explicadas anteriormente. Se uma chave de instruções pública de dono 271 foi instalada dentro do dispositivo de confiança 270, como mostrado na fig. 27, então as instruções de repetição de chave, repetição de garantia e transferência de propriedade de utilizador 272 não deverão ser processadas, a não ser que as instruções sejam assinadas 273 pela chave de assinatura privada de dono correspondente 274. Uma vez que a assinatura de dono 273 tenha sido verificada, o dispositivo de confiança 270 realiza os passos do procedimento de repetição de garantia, como descrito previamente. Assim, o dono não necessita de anexar um certificado de dono fornecendo a sua propriedade de um dispositivo numerado dado, quando se dão instruções ao dispositivo. No entanto, as instruções assinadas de dono devem é claro ser limitadas a um dispositivo numerado ou talvez a alguma classe de dispositivos cujos números de dispositivo se ajustam a uma regra dada ou modelo, a fim de evitar que as instruções sejam alimentadas para todos os dispositivos pertencentes a esse dono.
Adicionalmente, como mostrado na fig. 28, o dono pode enviar uma instrução para transferir a propriedade de dispositivo através da substituição da chave de verificação de instruções pública de dono, instalada originalmente com uma outra (do comprador, o novo dono do dispositivo). O dono do dispositivo envia uma instrução de transferência de propriedade 282 para o dispositivo 280, incluindo o novo nome de dono e chave de verificação de instruções pública, assinada utilizando a chave de assinatura de instruções privada de dono actual 283. O dispositivo verifica a instrução de transferência de propriedade 282, utilizando a chave de instruções pública de dono actual 281, substitui a chave pela nova chave de instruções pública 284 do dono e depois disso responde a instruções apenas do novo dono. Adicionalmente, o dono podia também adicionar outro "dono secundário” através da instalação de uma segunda chave de instruções pública. Esta segunda chave de verificação de instruções pública deveria ter um campo de "direitos", indicando que para quais operações é autorizado aceitar as instruções. 70 86 259 ΕΡ Ο 739 560/ΡΤ
Entre os direitos podem estar: a repetição de chave, a adição de outro dono, a eliminação de um dono (o mesmo de uma venda condicional), a eliminação de todos os donos, e o retrocesso para um dispositivo consumidor, que não tenha um dono declarado. No entanto, estes direitos definidos podem incluir mais ou menos direitos, ou a mesma quantidade de direitos, do que a chave de verificação de instruções primária ou original, incluindo o direito para substituir ou retirar a chave de instruções de dono primária.
Reaisto de dispositivo generalizado
Notar que os processos gerais anteriores, para garantir uma chave de decifração privada e receber um certificado de garantia, podem também ser aplicados para o mais caso geral de registar um dispositivo de confiança numa terceira parte de confiança e receber uma autorização da terceira parte que permite ao dispositivo comunicar com outros dispositivos confiáveis, não necessariamente limitado no âmbito ou finalidade à situação de garantia de chave. Neste processo geral, descrito na Fig. 24, um dispositivo de confiança programável 240, que comunica com uma terceira parte de confiança (TTP) 241, está equipado com uma chave de assinatura privada e um certificado 242 do fabricante para a chave de assinatura pública correspondente. O mesmo também contém cópias seguras das chaves públicas da autoridade de sistema geral (ou global) (SWA) de fabricante, as quais podem ser as mesmas, e suporte lógico inalterável de seguro a nível do sistema que pode suportar a instalação remota de suporte lógico inalterável adicional a nível da aplicação e chaves públicas relacionadas, como explicado algures nesta descrição. O dispositivo 240 pode registar com qualquer um de um número não limitado potencialmente dos TTP 241, que são admitidos neste sistema de registo geral, tendo sido emitido um certificado da autoridade 243, assinado pela SWA (a SWA pode também indicar um conjunto de certificadores para autorizar que os TTP sejam admitidos no sistema, de acordo com os princípios bem conhecidos das hierarquias de certificação de chave pública). Uma vez que os utilizadores tenham registado os seus dispositivos com um dado TTP, eles podem então empenharem-se em transações especializadas com outras partes de comerciais.
No primeiro passo deste processo, o utilizador inicia um pedido 244 para registar o seu dispositivo 240 com um dado certificado TTP 241. Este pedido 244 contém alguma informação 245 para identificar o utilizador e a natureza do pedido de registo e é assinado pelo dispositivo e acompanhado pelo certificado dc
86 259 ΕΡ Ο 739 560/ΡΤ 71 dispositivo 242 do fabricante a fim de atestar a assinatura e o tipo conhecido do dispositivo. O TTP 241 seleccionado pode também requerer outra informação e seguranças quer do utilizador quer de outras partes para verificar a identidade do utilizador, o filiação, o seu crédito, etc., os quais estão fora do âmbito deste protocolo, mas podem influenciar a decisão do TTP para garantir ou negar a autorização desejada de realizar transações. O TTP 241, utilizando as chaves públicas apropriadas, verifica a assinatura do fabricante no certificado de dispositivo 242 e a assinatura de dispositivo na informação 245 no pedido de registo 245 do utilizador.
Quando satisfeito que ao utilizador pode ser permitido empenhar-se na classe pedida de transações, o TTP 241 emite então uma resposta 246, contendo um certificado 247, que autoriza especificamente o dispositivo a realizar as transações em nome do utilizador. O certificado de autorização de dispositivo 247 do TTP deverá tipicamente conter informação de identificação o TTP, o utilizador, o dispositivo do utilizador, e as transações para as quais a permissão é concedida, bem como uma cópia certificada de novo da chave de assinatura pública de dispositivo do utilizador como uma questão de conveniência (e como mais tarde explicado), de modo que o utilizador não submete o seu certificado de dispositivo 242 em cada transação subsequente com os parceiros de negócio. A resposta de TTP 246 pode também conter suporte lógico inalterável carregável para baixo e ou chaves públicas 248 para serem carregadas no dispositivo de confiança do utilizador para lhe permitir a realização das transações autorizadas. Quando a resposta TTP 246 chama o utilizador para carregar de modo seguro novos suportes lógicos inalteráveis ou chaves públicas dentro do seu dispositivo, a resposta 246 deverá também incluir o certificado do TTP da autoridade 243 emitido pela SWA, certificando a chave de assinatura pública de TTP e conduzindo o suporte lógico inalterável e autoridade de actualização de chave pública. Quando o dispositivo de confiança 240 do utilizador recebe a resposta de TTP 246, o mesmo utiliza a sua chave de assinatura pública SWA incluída para verificar o certificado do TTP da autoridade 243 e utiliza a chave de assinatura pública TTP contida no mesmo para verificar o suporte lógico inalterável e as actualizações de chave pública 248 e o certificado de autorização de dispositivo 247 do TTP.
Referindo de novo a Fig. 24, quando o utilizador deseja realizar uma transação com um parceiro de negócio 250, o seu dispositivo deverá formular os dados de transação 249 de acordo com as regras anexas ao programa de suporte lógico inalterável instalado no dispositivo (ou na altura do fabrico ou no
86 250 ΕΡ 0 739 560/ΡΤ 72 carregamento subsequente), como foi extensamente explicado através desta descrição, e deverá assinar a transação 249 e anexar um certificado para a sua chave pública correspondente. Este certificado pode ser o certificado de disposilivo 242 do fabricante, mas ser mais provavelmente o certificado de autorização de dispositivo 247 do TTP, o qual contém uma cópia da chave pública de dispositivo certificada de novo por conveniência. O parceiro de negócio 250 deverá tipicamente utilizar a chave pública do TTP para verificar a assinatura do TTP no seu certificado de autorização de dispositivo 247 e utilizar então a chave de assinatura pública de dispositivo ali contida para verificar a assinatura do dispositivo na transação 249, confirmando, desse modo, a concordância do dispositivo com os requisitos de protocolo de transação impostos pelo suporte lógico inalterável relevante. No caso do parceiro de negócio 250 não ter já a chave de verificação de assinatura pública do TTP específico, o utilizador pode incluir na sua transação 249 o certificado de SWA do TTP da autoridade 243, o qual pode ser verificado pelo parceiro de negócio, utilizando a chave pública de SWA, a qual deve já possuir a fim de ser um participante neste sistema. O processo generalizado descrito até aqui é suficientemente geral para permitir (a) a garantia de uma chave de cifração privada em troca de um certificado de garantia, assinado por um centro de garantia (TTP), em que a informação contida ou implícita no certificado de dispositivo do utilizador conduz ao centro de garantia que o dispositivo está já equipado com suporte lógico inalterável que é capaz de realizar as funções especializadas do sistema de cifração de garantia de chave aqui descrito, ou (b) se tal dispositivo não está equipado dessa forma, mas é capaz de ser equipado dessa forma, o carregamento de uma actualização de suporte lógico segura, que durante a instalação deverá possibilitar ao dispositivo completar os requisitos transaccionais do sistema de garantia. Os dados de transação 249 enviados para o parceiro de negócio 250 pode ser uma mensagem cifrada previamente fixa por um cabeçalho de controlo de mensagem e acompanhada por uma autorização 247 (o certificado de garantia do utilizador), como emitido por um TTP 241 (o centro de garantia principal). O sistema generalizado da Fig. 24 possui, portanto, muitas propriedades altamente desejáveis as quais podem facilitar formas complexas de transações governamentais ou de negócio em ambientes de rede de comunicação aberta. Em particular, podem existir muitos fabricantes de dispositivo diferentes, desde que cada dispositivo participante seja capaz de executar transações de passos múltiplos seguras, carregar o suporte lógico Inalterável para realizar tipos adicionais 73 86 259 ΕΡ Ο 739 560/ΡΤ de transações de passos múltiplos seguras, e assinar as transações assim criadas. Também, pode existir qualquer número de terceiras partes confiáveis, emitindo cada uma delas um tipo diferente de autorização Iransaccional e criando e certificando cada uma delas uma classe diferente de aplicação de suporte lógico inalterável, tal como a garantia de chave, a gestão de dinheiro digital, o aluguer de carros ou a gestão de registos médicos de utilizador. Assim, embora possa ser exigido a um parceiro de negócio (pelo suporte lógico inalterável e protocolos do dispositivo de utilizador) para utilizar um dispositivo de confiança equipado comparativamente, o dispositivo pode ser feito, emitido e equipado por partes diferentes das do utilizador original, ainda as transações de utilizador original deverão ser ainda aceites e processadas de acordo com as regras do sistema, desde que a parte possua uma cópia da chave de verificação de assinatura pública de SWA 247, a qual permite que todas as versões dos dispositivos e os seus programas se reconheçam entre si e trabalhem em conjunto, se tal for certificado pela SWA e os seus TTP. Alguns exemplos de propósitos de negócio que podem ser cumpridos por este protocolo inclui sistemas que reforçam exigências transaccionais para (a) cifração utilizando provavelmente chaves de garantia, (b) gestão das representações digitais do dinheiro ou outros documentos de valor alto, e (c) acesso a informação pessoal médica ou outra do utilizador e utilização da mesma. Número único de identificação de dono
Dependendo da necessidade de equilibrar a facilidade de utilização com os direitos de privacidade, o número único de identificação de dono pode também aparecer opcionalmente em quer (a) o certificado de garantia de utilizador ou (b) MCH emitidos durante as comunicações normais, bem como nas mensagens de divisão de chave para os agentes de garantia. Seria desejável para um investigador, que tenta decifrar comunicações ser capaz de determinar ao olhar para um MCH, contendo o número de identificação do dono, se um ou ambos os dispositivos envolvidos na comunicação, a partir do qual o MCH que foi tirado pertence a um dado dono. No entanto, outros interesses de privacidade, incluindo os de certos donos, pode sugerir que o número de identificação de dono seja omitido do MCH a fim de melhorar a privacidade das comunicações. Nos casos, em que o número de identificação de dono é incluído apenas no certificado de garantia de dispositivo e não nos MCH das comunicações, um investigador, contratado por um empregador particular numa tentativa de determinar se uma comunicação particular, originada pelos empregados do empregador, confrontado com muitos MCH que não tenham donos de dispositivos listados, devem inquirir de um centro 74 86 259 ΕΡ Ο 739 560/ΡΤ de garantia principal, listado num dado MCH, se esse MCH originado por um dispositivo pertença do empregador. O centro de garantia principal deve decifrar o número de certificado de uma parte para a comunicação MCH, cujas chaves são garantidas pelo centro de garantia principal, e verificar se o certificado de utilizador foi emitido para o empregador do investigador. Se for assim e se o pedido do investigador é assinado, utilizando a chave de assinatura do empregador dono (isto é, o investigador tem autorização do empregador ou dono para investigar), o centro de garantia principal deve revelar esta informação. Se o investigador não tiver autorização, ao investigador deve então ser exigido procurar uma autorização ou autorização do tribunal para investigar actividades suspeitas reflectidas nos MCH de donos de dispositivos desconhecidos. É antecipado que a maioria dos donos dos dispositivos não se opõe a serem nomeados abertamente nos seus certificados de garantia de utilizador e MCH, porque na maioria dos sistemas de comunicações electrónicos é impossível suprimir a informação de endereço de rede física e lógica, que muitas vezes identifica fortemente a instituição remetente e receptora de uma dada mensagem. Assim, pouco é perdido ao publicitar os números únicos de identificação de dono, e muito é ganho ao proporcionar a capacidade de rapidamente aprofundar e classificar mensagens pelos nomes de dono de dispositivos remetentes e donos de dispositivo receptores. O número único de identificação de dono pode, no entanto, ainda ser incluído dentro do certificado de garantia do empregado ou dentro dos MCH das comunicações sem serem publicitados. O certificado de garantia do empregado e os MCH devem incluir uma chave de cifração pública de empregador em conjunto com as outras chaves, como descrito acima. Estas chaves devem normalmente estar presentes nos certificados tanto de remetente como de receptor (assumindo que tanto o remetente como o receptor têm empregadores). Quando o dispositivo do remetente forma o MCH, o mesmo deverá incluir dentro do MCH um ou ambos os números únicos de identificação de empregador, cada um cifrado utilizando a chave de cifração pública do respectivo empregador, a fim de que, com efeito, o dispositivo do remetente utiliza o MCH para enviar a cada empregador ou dono uma mensagem, que consiste na ID única própria de empregador ou dono respectivo, que apenas ele pode decifrar. Este processo é semelhante ao explicado acima com vista ao utilização do remetente do MCH para enviar os números de certificado tanto do remetente como do receptor cifrados com as chaves de cifração públicas dos seus respectivos centros de garantia, e para enviar a chave de sessão de mensagem para o receptor (a função normal do MCH), bem como para o remetente, a fim de permitir a escuta de ambas as partes. Esta técnica permite ao 75 86 259 ΕΡ Ο 739 560/ΡΤ empregador determinar prontamente quais os MCH que pertencem aos seus empregados, evitando ao mesmo tempo uma situação, na qual todas as mensagens pertencentes aos empregados do dono empregador são prontamenle identificáveis no fluxo de tráfego de mensagem e no qual os números de ID de dono não são cifrados e são prontamente obtidos.
Esta abordagem tem ainda a desvantagem do número único de identificação e empregador cifrado, utilizando a chave de cifração pública de empregador deverá sempre produzir o mesmo valor e, portanto, reconhecível. Uma melhor implementação desta abordagem deve ser cifrar um bloco de dados, contendo um selo de tempo corrente (ou outro número aleatório) em conjunto com o número de certificado de garantia do empregado (o qual o empregador tem claramente o direito de saber) com a chave pública do empregador, de modo que atribuição de selo de tempo deve dar uma alta variabilidade ao bloco de dados cifrado. Vários bytes de um texto que "prende a atenção" diferente, tal como "EMPR" (ou possivelmente a única ID do empregador, permitindo espaço) pode ser também incluído dentro do bloco cifrado a fim de fazer a decifração com sucesso óbvia para uma entidade que está a decifrar o campo (no caso de os outros itens de dados serem binários, caso em que não se pode ter a certeza). Neste caso, a prova da propriedade do empregador consiste simplesmente no empregador ser capaz de ler este campo. Adicionalmente, ainda um outro número aleatório podia ser adicionado ao bloco de dados para aumentar a variabilidade, no caso da atribuição de seio de tempo não ser suficientemente de confiança para ser diferente de cada vez e para, portanto, tornar os blocos de dados de MCH de empregador únicos.
Esta abordagem melhorada, a qual deve ser feita para os empregadores tanto do remetente como do receptor com todas as mensagens que são enviadas, deve tornar possível aos empregadores e a outros patrocinadores determinar quais comunicações foram geradas ou recebidas pelos seus empregados sem terem de submeter o MCH cifrado para cada comunicação ao centro de garantia apropriado para uma determinação se ou não qualquer destas comunicações foram originadas de um dispositivo pertença do empregador, economizando assim provavelmente uma quantidade de dinheiro considerável. Cada empregador deverá ainda ter de contactar o centro de garantia principal e os agentes de garantia, como anteriormente, a fim de obter a chave de cifração privada do seu empregado, e tem de provar que é de facto o dono do dispositivo do empregado, assinando os seus pedidos com a chave de assinatura privada, que coincide com a chave de verificação dc assinatura pública, contida no seu certificado de dono, como emitido 76 86 259 ΕΡ Ο 739 560/ΡΤ pelo fabricante de dispositivo. Pelo menos, os empregadores poupado em relação a tempo, esforço e despesa de quaisquer pedidos adicionais das partes, no que se refere aos MCH das comunicações, originadas a partir de qualquer paragem tardia, serem de dispositivos sem dono. E, como anteriormente, se um empregador suspeita de actividades criminosas ou outras impróprias em mensagens acompanhadas pelos MCH de comunicações de dispositivos sem dono, o empregador pode sempre contactar uma agência das forças da lei apropriada, contar a essa agência porque é que suspeita da actividade criminosa e tem a agência que ir ao tribunal para obter uma autorização para interceptar e/ou descodificar essas comunicações, as quais parecem ser originadas por terceiras partes criminosas não empregados ou, mais provavelmente, por indivíduos nas instalações do empregador, quer sejam empregados quer não, que estão a utilizar os dispositivos de cifração de que não são proprietários e registados para o empregador.
Este processo de colocar informação no MCH cifrado a fim de que a informação possa ser lida apenas pela parte autorizada a lar a mesma pode, obviamente, ser estendida a partes para além dos remetente e receptor (cada um dos quais pode decifrar a sua respectiva chave de sessão de mensagem do utilizador), cada centro de garantia principal da parte (cada um dos quais pode decifrar o ser respectivo número de certificado de utilizador), e cada dono ou empregador de parte (cada um dos quais pode decifrar o seu respectivo número de certificado de empregado ou o seu próprio número único de identificação de dono, a fim de confirmar se possui o dispositivo de comunicação sem ter de contactar qualquer um dos outros, enquanto que evita ser identificado em cada mensagem). Isto pode também ser estendido a outras partes tal como a divisões dentro de uma grande companhia ou, por exemplo, as forças da lei locais em certas nações estrangeiras que não têm requisitos de autorização. É claro, toda a Informação cifrada com estas chaves pode ser também mostrada em claro, isto é, não cifrada, como explicado anteriormente, desde que estas partes não tenham objecções a serem abertamente nomeadas e identificáveis por rotina em cada mensagem. Esta informação pode ser também omitida sempre que uma parte é irrelevante, por exemplo, quando um utilizador não tiver empregador. A abordagem mais simples deve ser utilizar um formato MCH para todas as situações, deixando campos em branco, quando não aplicáveis. Por outro lado, a concretização preferida deve ser utilizar vários formatos de MCH diferentes dentro do mesmo sistema, sendo cada formato identificado por um número único de versão no primeiro campo, a fim de que cada dispositivo, que processa um MCH deve ser capaz de determinar quais 77 86 259 ΕΡ Ο 739 560/ΡΤ os campos esperar e analisar de acordo o MCH. Este processo deve permitir uma introdução indefinida das partes interessadas no MCH, o que deveria ser o sistema mais flexível possível. A sobreposição de cálculo deve depender principalmenle de quantos destes campos devem de facto de ser cifrados com cada respectiva chave de cifração pública da parte.
Um empregador pode controlar mais facilmente a informação que está incluída no MCH acompanhando cada entrada com um "campo de política" ou um código de instruções que um código que dá as instruções ao dispositivo do empregador de qual a informação que deve ser incluída no MCH. Como anteriormente, o código de instruções pode incluir elementos de escolha, dando ao empregador opções de incluir as seguintes informações: (1) o nome do empregador e o número único de identificação, ou cifrados ou utilizando um pseudónimo; (2) a palavra "empregador” não cifrada, com o número único de identificação de empregador cifrado dentro do campo MCH; (3) o número de certificado de utilizador num campo cifrado; (4) a chave de sessão de mensagem num campo cifrado; (5) um selo de tempo num campo cifrado; e (6) um número para confundir aleatório dentro de qualquer dos outros campos cifrados. Muitas destas opções podem ser, com efeito, simultâneas. Além destas opções de política devem ser as mesmas para todos os membros da comunidade de interesses, incluindo as partes para as próprias comunicações, permitindo portanto que as partes sejam identificadas pelo seu correio ou ID de sistema ou simplesmente utilizando a palavra "remetente" ou "receptor" nos campos MCH em claro relevantes.
Chaves garantidas simultâneas múltiplas
Além das características acima descritas, para actualização das rotinas de suporte lógico inalterável de dispositivo e para substituição das chaves públicas do fabricante, o dispositivo de confiança deve ter também a capacidade de manter e gerir vários conjuntos de chaves de cifração de garantia simultaneamente. Normalmente, quando o dispositivo começa o ciclo de repetição de chave, isto é, a geração e garantia de uma nova chave de decifração privada, e como um resultado recebe um certificado de garantia para a correspondente nova chave de cifração pública, o dispositivo apagará a chave privada anterior a fim de reforçar a confiança do dispositivo na chave privada garantida recentemente. Em alternativa, o dispositivo pode reter a chave privada anterior durante apenas um período de tempo curto como necessário, por exemplo, pelo tempo necessário para recuperar dados cifrados dentro da armazenagem dc dados, utilizando o chave de cifração
86 259 ΕΡ Ο 739 560/ΡΤ 78 privada anterior. No entanto, numa concretização alternativa, o dispositivo pode também aceitar e processar uma instrução de nova garantia, ou do utilizador ou do dono do dispositivo como descrito acima, para criar um segundo certificado de garantia válido, respeitante ao mesmo par de chaves de cifração privadas/públicas. Nesta concretização, o dispositivo deve prosseguir com o processo de garantia, utilizando muito possivelmente uma lista diferente dos agentes de garantia e um centro de garantia principal diferente, e deve receber um certificado de garantia diferente e igualmente válido para o mesmo par de chaves de cifração públicas/privadas, que é assinado e emitido pelo segundo centro de garantia principal e pode ser utilizado de modo interpermutável com o primeiro certificado de garantia. Este segundo certificado de chave de cifração pública pode ser útil em casos, nos quais o utilizador do dispositivo viaja intemacionalmente ou se corresponde com partes localizadas noutros países, especialmente quando as outras nações podem desejar conduzir vigilâncias legítimas de comunicações, originadas ou terminadas nessas outras nações. Em tais casos, ao garantir de novo a mesma chave de dispositivo numa outra nação, o utilizador (ou o empregador do utilizador) pode ajudar a satisfazer possíveis requisitos legais nessa outra nação, enquanto que permite ainda ao utilizador ou empregador a conveniência de fazer negócios com o conjunto original dos agentes de garantia na sua própria nação (monitorização do dono legítimo, recuperação de chave perdida, etc.). Então, a fim de permitir ao dono seguir os MCH dos empregados, pode ser suficiente se as ID de dono dos remetente e receptor aparecessem em cada MCH, dizendo assim ao dono que ele tem a capacidade de obter a chave. Para poupar tempo e esforço, o dono pode então enviar um MCH para o centro de garantia principal estrangeiro para obter o número de certificado de garantia estrangeiro, o número de dispositivo subjacente e o certificado de dispositivo subjacente, mas depois valer-se dos seus agentes de garantia nacionais, os quais podem verificar o certificado do dono já em seu poder e libertar as divisões de chave privada reais. Este procedimento alivia o dono do dispositivo de quaisquer formalidades legais extra que podem ser requeridas a fim de obter as divisões de chave nacionais dos agentes de garantia estrangeiros.
Salvaguardas de exportação de segurança nacional A política normal do governo dos Estado Unidos é permitir o utilização sem regulamento de cifras dentro dos Estados Unidos por cidadãos americanos, mas impor pesadas restrições e multas para a exportação de dispositivos de cifração, suporte lógico ou "conhecimento" (“Know-How"). É possível modificar o presente t
86 259
EP 0 739 560/PT 79 sistema para permitir o utilização privada relativamente livre de dispositivos criptográficos nos Estados Unidos, impondo ao mesmo tempo restrições na sua utilização internacional. Um tal sistema pode permitir "domínios de políLica” inler-operáveis separados, que estão abertos a todos os vendedores de suporte lógico e suporte físico com mínimas ou sem alterações de concepção dos formatos de mensagem padrão utilizados através do sistema. É ainda desejável permitir a utilização de agentes de garantia privados em situações de país único puramente entre corporações, nas quais o sistema de garantia de chave está a ser utilizado unicamente para permitir a uma corporação particular controlar e vigiar as utilizações de cifração dos seus próprios empregados, sem qualquer obrigação, expressa ou implícita, de facilitar o acesso das forças da lei às comunicações que foram cifradas, utilizando chaves que a corporação garantiu. Em particular, tais companhias podem comprar os suporte lógico e suporte físico para sua própria utilização, mas podem negar assumir qualquer dever público de fornecer acesso a chaves privadas em intervalos de tempo curto, como pode ser desejado pelas forças da lei na perseguição de criminosos ou terroristas.
Isto pode ser feito, assumindo, em primeiro lugar, que todos os dispositivos através do sistema estão ligados directa ou indirectamente a uma autoridade de sistema geral (SWA) que (como anteriormente descrito) emite certificados para agentes de garantia, centros de garantia principais e fabricantes de dispositivos, a fim de permitir que cada um seja reconhecido pelos dispositivos dentro do sistema como sendo autêntico e verdadeiro. Um sistema de comunicações global ou nacional deve, por razões práticas, suportar a existência de agentes e centros de garantia principais múltiplos e não relacionados, cada um dos quais deve ser certificado pelo SWA como sendo autêntico. Em cada certificado emitido para um centro de garantia principal ou para um agente de garantia, o SWA indicá-lo-á como "público" ou "privado". Um agente de garantia ou centro de garantia "público" é o que está equipado e obrigado a responder rapidamente a autorizações ou intimações das forças da lei ou da segurança nacional. Os utilizadores cujas chaves são garantidas por tais agentes podem ser autorizados a efectuar comunicações além fronteiras. Um agente de garantia ou centro de garantia principal "privado” inclui os centros de chave de país único ou de companhias únicas que têm instalada tecnologia de sistema de garantia de chave para sua própria utilização mas não assumem qualquer obrigação a um nível público de serviço. O certificado da SWA para o centro de garantia principal ou agente de garantia deverá também incluir um código de país. Então, cada certificado de garantia do utilizador que é emitido c assinado por um centro de garantia principal e tem o certificado de SWA
86 259 ΕΡ Ο 739 560/ΡΤ 80 de centro de garantia principal anexo deverá também levar o código de país do utilizador. Notar que, como uma questão de conveniência, o certificado de garantia do utilizador deve também declarar que o mesmo é originado por um agente de garantia público ou não público, embora possa não ser possível para a SWA reforçar a exactidão dessa informação. Isto pode permitir ao dispositivo tornar estas regras ainda mais fáceis do que exigir sempre o certificado de SWA do centro de garantia principal.
As Figs. 29 e 30 mostram a implementação do requisito de garantia quando enviando e recebendo comunicações criptográficas internacionais. Como mostrado na Fig. 29, o dispositivo de confiança 290 do remetente implementa este sistema requerendo os certificados de garantia 291, 293 tanto do remetente como do receptor, e, se o remetente e o receptor não estão garantidos no mesmo centro de garantia principal, os seus certificados SWA de centro de garantia principais 292, 294, antes de enviar uma comunicação internacional. Os códigos de país 295, 296 · do utilizador receptor e o seu centro de garantia principal devem coincidir a fim de que um dispositivo remetente 290 envie uma comunicação. Além disso, se o remetente e o receptor estão em países diferentes 295, 297 e se qualquer utilizador está a utilizar um centro de garantia principal não público 298, 299, o dispositivo remetente recusará originar uma comunicação para esse receptor. Como mostrado na Fig. 30, o dispositivo de confiança de receptor 300 deverá também implementar este sistema recusando decifrar uma comunicação, se uma é de qualquer maneira originada, na qual o remetente e o receptor estão em diferentes países e se qualquer dos utilizadores está a utilizar um centro de garantia principal não público. Estas regras efectuarão a política desejada de desaprovação de comunicações criptográficas internacionais não garantidas, porque o centro de garantia principal não pode falsificar o seu estatuto público, o qual é certificado pela SWA, e, mesmo que o centro de garantia principal possa falsificar o código de país do utilizador (para fazer com que o utilizador apareça como pertencendo a um domínio estrangeiro), os dispositivos não permitirão uma discrepância entre os códigos de país do utilizador e do centro de garantia principal. Embora estas regras não evitem que um utilizador transporte de modo impróprio o seu dispositivo de cifração de confiança através das fronteiras nacionais, elas permitem uma satisfação fácil com os requisitos nacionais permitindo-lhe manter uma chave garantida em cada nação e comunicar utilizando apenas a chave apropriada em cada domínio de política. 81 86 250 ΕΡ 0 739 560/ΡΤ
Versões de dispositivo utilizadores múltiplos
Uma outra caraoleríslica deste invento é a capacidade para iniciar e gerir simultaneamente várias sessões diferentes de comunicações com utilizadores diferentes locais ou afastados, utilizando o mesmo dispositivo. Muitos computadores grandes suportam utilizadores múltiplos, os quais estão frequentemente registados simultaneamente através de sessões de terminal, mas que podem desejar iniciar sessões cifradas com outras entidades em todo o mundo. No entanto, porque deve ser altamente ineficiente exigir um dispositivo de confiança separado para cada sessão de utilizador num computador repartido, o dispositivo de confiança pode seguir a chave de sessão de mensagem para cada comunicação ao armazená-la em conjunto com um número único de sequência de mensagem (MSN) para a sessão. Então, quando qualquer pacotes de mensagem adicionais que apoiam esse MSN chegam, os mesmos podem ser decifrados, e as respostas cifradas, sem demora. Além disso, o dispositivo pode garantir as chaves de decifração privadas de vários utilizadores enquanto liga cada chave privada de utilizador ao um número de identificação único de utilizador e permite que cada chave seja utilizada apenas na apresentação de alguma autenticação de utilizador adequada, tal como uma palavra passe, cartão inteligente, PIN, biométrico, resposta de. desafio, etc. Ao atribuir um número de identificação de utilizador e senha ou o equivalente a cada par de chaves públicas/privadas como é gerado para garantia, os controlos normais em senhas, tal como comprimento, expiração, bloqueios de retracção e facilidade de adivinhar, podiam então ser impostos pelo dispositivo a fim de limitar a possibilidade de acesso não autorizado.
Assim, é fornecido um sistema e processo criptográfico com característica de garantia de chave. Um especialista na técnica apreciará que o presente invento pode ser posto em prática por outras que não as concretizações descritas, as quais são apresentadas para fins de ilustração e não de limitação, e o presente invento é limitado apenas pelas reivindicações que se seguem.
Por CERTCO INCORPORATED
Eng.° ANTÓNIO JO&O DA CUNHA FERREIRA
Ag. Of· Pr. Ind·
Rua das Flores, 74-4·,° 1200-185 LISBOA

Claims (20)

  1. 06 259 ΕΡ 0 739 560/ΡΤ 1/4 REIVINDICAÇÕES 1 - Processo para geração comunicações com fluxo orientado, confiáveis de modo verificável, entre uma pluralidade de utilizadores, compreendendo os passos de: garantir, num centro de garantia de confiança (153, 165), uma chave criptográfica assimétrica (151), associada a cada um de uma pluralidade de utilizadores; verificar cada uma das chaves (151) no centro de garantia (153,165); certificar cada uma das chaves (151) depois da verificação; e gerar uma comunicação com fluxo orientado, cifrada a partir de um utilizador de iniciação para um utilizador de recepção, utilizando a dita chave criptográfica do utilizador de iniciação (151), caracterizado por a dita comunicação compreender (a) um pacote inicial, tendo informação de acesso de chave de decifração de mensagem para permitir que uma terceira parte decifre o fluxo, e (b) um fluxo de pacotes subsequentes, contendo cada pacote subsequente informação de identificação do pacote subsequente, como associado ao fluxo, e no qual, pelo menos, um dos ditos pacotes subsequentes não inclui a dita informação de acesso de chave de decifração de mensagem.
  2. 2 - Processo de acordo com a reivindicação 1, em que a comunicação compreende ainda um pacote terminal, tendo informação que indica um final da comunicação.
  3. 3 - Processo de acordo com a reivindicação 1 ou reivindicação 2, em que cada pacote subsequente inclui ainda informação única, que indica uma posição do pacote dentro da sequência.
  4. 4 - Processo de acordo com a reivindicação 1 ou reivindicação 2, em que cada pacote subsequente inclui ainda informação de atribuição de selo de tempo (213). ΕΡ Ο 739 560/ΡΤ 2/4
  5. 5 - Processo de acordo com qualquer uma das reivindicações anteriores, em que a informação de acesso de chave de decifração de mensagem inclui uma informação não válida do pacote inicial.
  6. 6 - Processo de acordo com a reivindicação 5, em que a dita informação não válida do dito pacote inicial é assinada com a chave criptográfica (151) do utilizador de iniciação.
  7. 7 - Processo de acordo com a reivindicação 6, em que a dita informação de acesso de chave de decifração de mensagem inclui ainda informação de identificação de mensagem.
  8. 8 - Processo de acordo com a reivindicação 7, em que, pelo menos, um dos pacotes subsequentes inclui a informação de identificação de mensagem.
  9. 9 - Processo de acordo com a reivindicação 8, em que a dita informação de identificação do pacote subsequente como associado ao fluxo é um número de sequência de pacote.
  10. 10 - Processo de acordo com qualquer uma das reivindicações anteriores, compreendendo ainda os passos de: receber, no utilizador de iniciação, informação relacionada com uma qualidade de um canal portador da comunicação com fluxo orientado; e incluir selectivamente a informação de identificação de mensagem em pacotes subsequentes a uma velocidade determinada pela qualidade do canal.
  11. 11 - Processo de acordo com qualquer uma das reivindicações anteriores, em que os pacotes incluem informação que associa os mesmos ao utilizador de iniciação.
  12. 12 - Processo para geração de comunicações com fluxo orientado, confiáveis de modo verificável, entre uma pluralidade de utilizadores, compreendendo os passos de:
    86 259 ΕΡ Ο 739 560/ΡΤ 3/4 garantir num centro de garantia de confiança (153, 165) uma chave criptográfica assimétrica (151), associada a cada um de uma pluralidade de utilizadores; verificar cada uma das chaves (151) no centro de garantia (153, 165); certificar cada uma das chaves (151) depois da verificação; e receber, num utilizador de recepção, uma primeira comunicação com fluxo orientado e cifrada de um utilizador de iniciação, tendo a dita comunicação sido cifrada, utilizando a chave criptográfica (151) do utilizador de iniciação; caracterizado em que a dita primeira comunicação compreende (a) um pacote inicial, tendo informação de acesso de chave de decifração de mensagem, para permitir que uma terceira parte possa decifrar o fluxo, e (b) um fluxo de pacotes subsequentes, contendo cada pacote subsequente informação de identificação do pacote subsequente como associado ao fluxo, e em que, pelo menos, um pacote subsequente do primeiro fluxo não inclui a dita informação de acesso de chave de decifração de mensagem.
  13. 13 - Processo de acordo com a reivindicação 12, compreendendo ainda os passos de: gerar uma segunda comunicação com fluxo orientado cifrada a partir do utilizador de recepção para um utilizador de iniciação, utilizando uma chave criptográfica do utilizador de recepção, compreendendo a dita segunda comunicação (a) um pacote inicial, tendo informação de acesso de chave de decifração de mensagem, para permitir a uma terceira parte decifrar o segundo fluxo cifrado, e (b) um fluxo de pacotes subsequentes, contendo cada pacote subsequente informação de identificação do pacote subsequente como associado ao segundo fluxo cifrado.
  14. 14 - Processo de acordo com a reivindicação 13, em que a informação de acesso de chave de decifração de mensagem, do segundo fluxo cifrado, inclui uma informação não válida do pacote inicial do segundo fluxo cifrado, assinado com a chave criptográfica do utilizador de recepção. 86 259 ΕΡ Ο 739 560/ΡΤ 4/4
  15. 15 - Processo de acordo com a reivindicação 14, em que a informação de acesso de chave de decifração de mensagem, do segundo fluxo cifrado, inclui informação de idenlillcação de mensagem recebida do utilizador de iniciação.
  16. 16 - Processo de acordo com a reivindicação 15, em que, pelo menos, um dos pacotes subsequentes, do segundo fluxo cifrado, inclui informação de identificação de mensagem.
  17. 17 - Processo de acordo com a reivindicação 16, em que a informação de identificação de um pacote subsequente do segundo fluxo cifrado como associado ao segundo fluxo cifrado é um número de sequência de pacote.
  18. 18 - Processo de acordo com a reivindicação 17, em que os pacotes do segundo fluxo cifrado inclui informação associando-os com o utilizador de iniciação.
  19. 19 - Processo de acordo com qualquer das reivindicações 13 a 18, compreendendo adicionalmente os passos de: receber, no utilizador de recepção, informação relacionada com uma qualidade de um canal portador da comunicação com fluxo orientado; e incluir selectivamente informação de identificação de mensagem em pacotes subsequentes a uma velocidade determinada pela qualidade do canal.
  20. 20 - Processo da reivindicação 19, em que a informação relacionada com uma qualidade do canal é continuamente recebida e a velocidade à qual a informação de identificação é selectivamente incluída em pacotes subsequentes é dinamicamente ajustada com base na informação recebida. Lisboa, Zj. 3 ?001· Por CERTCO INCORPORATED -O AGEIUE.QE1CJAU-
    Eng.° ANTÓNIO JOÃO DA CUNHA FERRE1RA Ag. Of. Pr. Ind. Rua das Flores, 74-4.° 1200-195 LISBOA
PT95908511T 1994-01-13 1995-01-13 Sistema criptografico e processo com caracteristica de garantia de chave PT739560E (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US18185994A 1994-01-13 1994-01-13
US27220394A 1994-07-08 1994-07-08

Publications (1)

Publication Number Publication Date
PT739560E true PT739560E (pt) 2001-12-28

Family

ID=26877578

Family Applications (1)

Application Number Title Priority Date Filing Date
PT95908511T PT739560E (pt) 1994-01-13 1995-01-13 Sistema criptografico e processo com caracteristica de garantia de chave

Country Status (22)

Country Link
US (6) US5872849A (pt)
EP (1) EP0739560B1 (pt)
JP (4) JPH09507729A (pt)
CN (1) CN1138927A (pt)
AP (1) AP626A (pt)
AT (1) ATE202439T1 (pt)
AU (1) AU1680395A (pt)
BR (1) BR9506414A (pt)
CA (1) CA2176032A1 (pt)
CZ (1) CZ197896A3 (pt)
DE (1) DE69521413T2 (pt)
DK (1) DK0739560T3 (pt)
ES (1) ES2158081T3 (pt)
GR (1) GR3036650T3 (pt)
HU (1) HU216231B (pt)
MX (1) MX9602773A (pt)
NZ (2) NZ279622A (pt)
OA (1) OA10456A (pt)
PL (1) PL176458B1 (pt)
PT (1) PT739560E (pt)
UA (1) UA41387C2 (pt)
WO (1) WO1995019672A2 (pt)

Families Citing this family (678)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5557518A (en) 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
US6267670B1 (en) * 1997-03-21 2001-07-31 Walker Digital, Llc System and method for performing lottery ticket transactions utilizing point-of-sale terminals
JPH07271865A (ja) 1994-04-01 1995-10-20 Mitsubishi Corp データベース著作権管理方法
US6088797A (en) * 1994-04-28 2000-07-11 Rosen; Sholom S. Tamper-proof electronic processing device
US7302415B1 (en) 1994-09-30 2007-11-27 Intarsia Llc Data copyright management system
US6424715B1 (en) 1994-10-27 2002-07-23 Mitsubishi Corporation Digital content management system and apparatus
DE69532434T2 (de) * 1994-10-27 2004-11-11 Mitsubishi Corp. Gerät für Dateiurheberrechte-Verwaltungssystem
US6324558B1 (en) * 1995-02-14 2001-11-27 Scott A. Wilber Random number generator and generation method
US6272632B1 (en) * 1995-02-21 2001-08-07 Network Associates, Inc. System and method for controlling access to a user secret using a key recovery field
DE19514084C1 (de) * 1995-04-13 1996-07-11 Siemens Ag Verfahren zum rechnergestützten Austausch kryptographischer Schlüssel zwischen einer Benutzercomputereinheit U und einer Netzcomputereinheit N
EP0760565B1 (en) * 1995-08-28 1998-07-08 Ofra Feldbau Apparatus and method for authenticating the dispatch and contents of documents
US8595502B2 (en) 1995-09-29 2013-11-26 Intarsia Software Llc Data management system
US8015597B2 (en) 1995-10-02 2011-09-06 Corestreet, Ltd. Disseminating additional data used for controlling access
US7353396B2 (en) * 1995-10-02 2008-04-01 Corestreet, Ltd. Physical access control
US6766450B2 (en) 1995-10-24 2004-07-20 Corestreet, Ltd. Certificate revocation system
US7600129B2 (en) 1995-10-02 2009-10-06 Corestreet, Ltd. Controlling access using additional data
US7822989B2 (en) 1995-10-02 2010-10-26 Corestreet, Ltd. Controlling access to an area
US7337315B2 (en) * 1995-10-02 2008-02-26 Corestreet, Ltd. Efficient certificate revocation
US7716486B2 (en) * 1995-10-02 2010-05-11 Corestreet, Ltd. Controlling group access to doors
US8732457B2 (en) 1995-10-02 2014-05-20 Assa Abloy Ab Scalable certificate validation and simplified PKI management
US8261319B2 (en) 1995-10-24 2012-09-04 Corestreet, Ltd. Logging access attempts to an area
US5774552A (en) * 1995-12-13 1998-06-30 Ncr Corporation Method and apparatus for retrieving X.509 certificates from an X.500 directory
US6026163A (en) * 1995-12-13 2000-02-15 Micali; Silvio Distributed split-key cryptosystem and applications
US5995630A (en) * 1996-03-07 1999-11-30 Dew Engineering And Development Limited Biometric input with encryption
US5669975A (en) * 1996-03-27 1997-09-23 Sony Corporation Plasma producing method and apparatus including an inductively-coupled plasma source
US8549310B2 (en) * 1996-04-08 2013-10-01 Walker Digital, Llc Method and apparatus for secure measurement certification
US5815573A (en) * 1996-04-10 1998-09-29 International Business Machines Corporation Cryptographic key recovery system
WO1997043761A2 (en) * 1996-05-15 1997-11-20 Intertrust Technologies Corp. Cryptographic methods, apparatus and systems for storage media electronic rights management in closed and connected appliances
AU5340500A (en) * 1996-06-13 2000-11-02 Intel Corporation Method for verifying integrity on an apparatus
US5901227A (en) * 1996-06-20 1999-05-04 Novell, Inc. Method and apparatus for implementing partial and complete optional key escrow
US5913921A (en) * 1996-07-12 1999-06-22 Glenayre Electronics, Inc. System for communicating information about nodes configuration by generating advertisements having era values for identifying time reference for which the configuration is operative
US5796830A (en) * 1996-07-29 1998-08-18 International Business Machines Corporation Interoperable cryptographic key recovery system
US20040199402A1 (en) * 1996-09-06 2004-10-07 Walker Jay S. Method and system for anonymous communication of information about a home
US6212634B1 (en) * 1996-11-15 2001-04-03 Open Market, Inc. Certifying authorization in computer networks
US6192131B1 (en) 1996-11-15 2001-02-20 Securities Industry Automation Corporation Enabling business transactions in computer networks
US8225089B2 (en) 1996-12-04 2012-07-17 Otomaku Properties Ltd., L.L.C. Electronic transaction systems utilizing a PEAD and a private key
US5917913A (en) * 1996-12-04 1999-06-29 Wang; Ynjiun Paul Portable electronic authorization devices and methods therefor
US6708221B1 (en) * 1996-12-13 2004-03-16 Visto Corporation System and method for globally and securely accessing unified information in a computer network
US7287271B1 (en) 1997-04-08 2007-10-23 Visto Corporation System and method for enabling secure access to services in a computer network
US20060195595A1 (en) 2003-12-19 2006-08-31 Mendez Daniel J System and method for globally and securely accessing unified information in a computer network
US6353812B2 (en) * 1998-02-19 2002-03-05 Certco, Inc. Computer-based method and system for aiding transactions
US5917911A (en) * 1997-01-23 1999-06-29 Motorola, Inc. Method and system for hierarchical key access and recovery
US6055575A (en) * 1997-01-28 2000-04-25 Ascend Communications, Inc. Virtual private network system and method
US7212632B2 (en) 1998-02-13 2007-05-01 Tecsec, Inc. Cryptographic key split combiner
US5920630A (en) * 1997-02-25 1999-07-06 United States Of America Method of public key cryptography that includes key escrow
US7003480B2 (en) * 1997-02-27 2006-02-21 Microsoft Corporation GUMP: grand unified meta-protocol for simple standards-based electronic commerce transactions
GB9704159D0 (en) * 1997-02-28 1997-04-16 Neopost Ltd Security and authentication of postage indicia
US7233912B2 (en) 1997-08-26 2007-06-19 Walker Digital, Llc Method and apparatus for vending a combination of products
US6477513B1 (en) * 1997-04-03 2002-11-05 Walker Digital, Llc Method and apparatus for executing cryptographically-enabled letters of credit
US6766454B1 (en) 1997-04-08 2004-07-20 Visto Corporation System and method for using an authentication applet to identify and authenticate a user in a computer network
US6289451B1 (en) * 1997-04-18 2001-09-11 Sun Microsystems, Inc. System and method for efficiently implementing an authenticated communications channel that facilitates tamper detection
US6694433B1 (en) * 1997-05-08 2004-02-17 Tecsec, Inc. XML encryption scheme
EP0983661A1 (en) * 1997-05-09 2000-03-08 Neomedia Technologies, Inc Method and system for accessing electronic resources via machine-readable data on intelligent documents
CN1139894C (zh) * 1997-05-09 2004-02-25 Gte服务公司 认证电子交易的生物特征认证系统和方法
US6381698B1 (en) * 1997-05-21 2002-04-30 At&T Corp System and method for providing assurance to a host that a piece of software possesses a particular property
JP2002500842A (ja) * 1997-05-28 2002-01-08 ルーカス ヤング，アダム 自働回復及び自働認証可能暗号システム
US6202150B1 (en) * 1997-05-28 2001-03-13 Adam Lucas Young Auto-escrowable and auto-certifiable cryptosystems
US6314190B1 (en) 1997-06-06 2001-11-06 Networks Associates Technology, Inc. Cryptographic system with methods for user-controlled message recovery
US6311171B1 (en) * 1997-07-11 2001-10-30 Ericsson Inc. Symmetrically-secured electronic communication system
US6212635B1 (en) * 1997-07-18 2001-04-03 David C. Reardon Network security system allowing access and modification to a security subsystem after initial installation when a master token is in place
US6058188A (en) * 1997-07-24 2000-05-02 International Business Machines Corporation Method and apparatus for interoperable validation of key recovery information in a cryptographic system
US6370249B1 (en) * 1997-07-25 2002-04-09 Entrust Technologies, Ltd. Method and apparatus for public key management
DE19733662C2 (de) * 1997-08-04 2001-05-23 Deutsche Telekom Mobil Verfahren und Vorrichtung zur kundenseitigen Personalisierung von GSM-Chips
US6278782B1 (en) 1997-09-16 2001-08-21 Safenet, Inc. Method of implementing a key recovery system
US6128391A (en) * 1997-09-22 2000-10-03 Visa International Service Association Method and apparatus for asymetric key management in a cryptographic system
US5970147A (en) * 1997-09-30 1999-10-19 Intel Corporation System and method for configuring and registering a cryptographic device
US6357004B1 (en) 1997-09-30 2002-03-12 Intel Corporation System and method for ensuring integrity throughout post-processing
US6052784A (en) * 1997-10-14 2000-04-18 Intel Corporation Network discovery system and method
ES2173652T5 (es) * 1997-10-28 2010-10-13 First Data Mobile Holdings Limited Procedimiento para la firma digital de un mensaje.
US6035398A (en) * 1997-11-14 2000-03-07 Digitalpersona, Inc. Cryptographic key generation using biometric data
US6128735A (en) * 1997-11-25 2000-10-03 Motorola, Inc. Method and system for securely transferring a data set in a data communications system
US6246771B1 (en) * 1997-11-26 2001-06-12 V-One Corporation Session key recovery system and method
GB2331898B (en) * 1997-12-01 2003-03-12 Hewlett Packard Co Fair escrow cryptosystems
US6151395A (en) * 1997-12-04 2000-11-21 Cisco Technology, Inc. System and method for regenerating secret keys in diffie-hellman communication sessions
US6108788A (en) * 1997-12-08 2000-08-22 Entrust Technologies Limited Certificate management system and method for a communication security system
US7587044B2 (en) 1998-01-02 2009-09-08 Cryptography Research, Inc. Differential power analysis method and apparatus
JP4496440B2 (ja) * 1998-01-12 2010-07-07 ソニー株式会社 暗号化コンテンツ送信装置
US6055636A (en) * 1998-01-27 2000-04-25 Entrust Technologies, Limited Method and apparatus for centralizing processing of key and certificate life cycle management
US6185624B1 (en) 1998-02-04 2001-02-06 3Com Corporation Method and system for cable modem management of a data-over-cable system
US6058421A (en) * 1998-02-04 2000-05-02 3Com Corporation Method and system for addressing network host interfaces from a cable modem using DHCP
US6070246A (en) * 1998-02-04 2000-05-30 3Com Corporation Method and system for secure cable modem initialization
US6240464B1 (en) 1998-02-04 2001-05-29 3Com Corporation Method and system for managing addresses for network host interfaces in a data-over-cable system
US6065049A (en) * 1998-02-04 2000-05-16 3Com Corporation Method and system for resolving addresses for network host interfaces from a cable modem
US6049826A (en) * 1998-02-04 2000-04-11 3Com Corporation Method and system for cable modem initialization using dynamic servers
US6170061B1 (en) 1998-02-04 2001-01-02 3Com Corporation Method and system for secure cable modem registration
EP0936805A1 (en) * 1998-02-12 1999-08-18 Hewlett-Packard Company Document transfer systems
US8077870B2 (en) * 1998-02-13 2011-12-13 Tecsec, Inc. Cryptographic key split binder for use with tagged data elements
US7079653B2 (en) * 1998-02-13 2006-07-18 Tecsec, Inc. Cryptographic key split binding process and apparatus
EP0946019A1 (en) 1998-03-25 1999-09-29 CANAL+ Société Anonyme Authentification of data in a digital transmission system
US6725373B2 (en) * 1998-03-25 2004-04-20 Intel Corporation Method and apparatus for verifying the integrity of digital objects using signed manifests
EP0994599A4 (en) * 1998-04-01 2009-06-03 Panasonic Corp DATA TRANSMITTING / RECEIVING METHOD, DATA TRANSMITTER, DATA RECEIVER, DATA TRANSMITTING / RECEIVING SYSTEM, AUDIOVISUAL CONTENT TRANSMITTING METHOD, AUDIOVISUAL CONTENT RECEIVING METHOD, AUDIOVISUAL CONTENT TRANSMITTER, AUDIOVISUAL CONTENT RECEIVER , AND RECORD SUPPORT
US6970836B1 (en) * 1998-04-14 2005-11-29 Citicorp Development Center, Inc. System and method for securely storing electronic data
US6370147B1 (en) 1998-04-23 2002-04-09 3Com Corporation Method for addressing of passive network hosts in a data-over-cable system
US6240512B1 (en) * 1998-04-30 2001-05-29 International Business Machines Corporation Single sign-on (SSO) mechanism having master key synchronization
US6928546B1 (en) * 1998-05-14 2005-08-09 Fusion Arc, Inc. Identity verification method using a central biometric authority
US6223222B1 (en) 1998-05-14 2001-04-24 3Com Corporation Method and system for providing quality-of-service in a data-over-cable system using configuration protocol messaging
US6636485B1 (en) 1998-05-14 2003-10-21 3Com Corporation Method and system for providing quality-of-service in a data-over-cable system
US6233341B1 (en) * 1998-05-19 2001-05-15 Visto Corporation System and method for installing and using a temporary certificate at a remote site
JPH11331618A (ja) * 1998-05-19 1999-11-30 Canon Inc 画像処理装置、画像データ配布装置、画像データ配布システム、画像データ配布方法、及び記憶媒体
US6442158B1 (en) 1998-05-27 2002-08-27 3Com Corporation Method and system for quality-of-service based data forwarding in a data-over-cable system
US6775276B1 (en) 1998-05-27 2004-08-10 3Com Corporation Method and system for seamless address allocation in a data-over-cable system
US6331987B1 (en) 1998-05-27 2001-12-18 3Com Corporation Method and system for bundling data in a data-over-cable system
US6560203B1 (en) 1998-05-27 2003-05-06 3Com Corporation Method for changing type-of-service in a data-over-cable system
US6510162B1 (en) 1998-05-27 2003-01-21 3Com Corporation System and method for managing channel usage in a data over cable system
US6189102B1 (en) 1998-05-27 2001-02-13 3Com Corporation Method for authentication of network devices in a data-over cable system
US6275853B1 (en) 1998-05-27 2001-08-14 3Com Corporation System and method for extending communications features using generic management information base objects
US6295554B1 (en) 1998-05-27 2001-09-25 3Com Corporation System and method for communicating with a telco-return cable modem as a single communications device
US6539092B1 (en) 1998-07-02 2003-03-25 Cryptography Research, Inc. Leak-resistant cryptographic indexed key update
US6336186B1 (en) 1998-07-02 2002-01-01 Networks Associates Technology, Inc. Cryptographic system and methodology for creating and managing crypto policy on certificate servers
US6442686B1 (en) 1998-07-02 2002-08-27 Networks Associates Technology, Inc. System and methodology for messaging server-based management and enforcement of crypto policies
US6566858B1 (en) * 1998-07-10 2003-05-20 Silverbrook Research Pty Ltd Circuit for protecting chips against IDD fluctuation attacks
US6816968B1 (en) * 1998-07-10 2004-11-09 Silverbrook Research Pty Ltd Consumable authentication protocol and system
EP1095484B1 (en) * 1998-07-15 2007-06-27 International Business Machines Corporation Method of establishing the trustworthiness level of a participant in a communication connection
US6751729B1 (en) * 1998-07-24 2004-06-15 Spatial Adventures, Inc. Automated operation and security system for virtual private networks
US6226618B1 (en) * 1998-08-13 2001-05-01 International Business Machines Corporation Electronic content delivery system
US6085321A (en) 1998-08-14 2000-07-04 Omnipoint Corporation Unique digital signature
US6356935B1 (en) 1998-08-14 2002-03-12 Xircom Wireless, Inc. Apparatus and method for an authenticated electronic userid
US6615348B1 (en) 1999-04-16 2003-09-02 Intel Corporation Method and apparatus for an adapted digital signature
US6591364B1 (en) * 1998-08-28 2003-07-08 Lucent Technologies Inc. Method for establishing session key agreement
US7111173B1 (en) * 1998-09-01 2006-09-19 Tecsec, Inc. Encryption process including a biometric unit
RU2153191C2 (ru) 1998-09-29 2000-07-20 Закрытое акционерное общество "Алкорсофт" Способ изготовления вслепую цифровой rsa-подписи и устройство для его реализации (варианты)
US6892229B1 (en) 1998-09-30 2005-05-10 3Com Corporation System and method for assigning dynamic host configuration protocol parameters in devices using resident network interfaces
US6212563B1 (en) 1998-10-01 2001-04-03 3Com Corporation Method and system for setting and managing externally provided internet protocol addresses using the dynamic host configuration protocol
CA2347176A1 (en) 1998-10-23 2000-05-04 L-3 Communications Corporation Apparatus and methods for managing key material in heterogeneous cryptographic assets
US7386727B1 (en) 1998-10-24 2008-06-10 Encorus Holdings Limited Method for digital signing of a message
US6829712B1 (en) * 1998-10-27 2004-12-07 Sprint Communications Company L.P. Object-based security system
US6820202B1 (en) * 1998-11-09 2004-11-16 First Data Corporation Account authority digital signature (AADS) system
US7047416B2 (en) * 1998-11-09 2006-05-16 First Data Corporation Account-based digital signature (ABDS) system
RU2157001C2 (ru) 1998-11-25 2000-09-27 Закрытое акционерное общество "Алкорсофт" Способ проведения платежей (варианты)
US6473861B1 (en) * 1998-12-03 2002-10-29 Joseph Forte Magnetic optical encryption/decryption disk drive arrangement
US6662135B1 (en) 1998-12-09 2003-12-09 3Com Corporation Method and apparatus for reflective mixer testing of a cable modem
US6307955B1 (en) * 1998-12-18 2001-10-23 Topaz Systems, Inc. Electronic signature management system
US6351773B1 (en) 1998-12-21 2002-02-26 3Com Corporation Methods for restricting access of network devices to subscription services in a data-over-cable system
US6657991B1 (en) 1998-12-21 2003-12-02 3Com Corporation Method and system for provisioning network addresses in a data-over-cable system
US6986157B1 (en) 1998-12-21 2006-01-10 3Com Corporation Method and system for dynamic service registration in a data-over-cable system
US7209889B1 (en) * 1998-12-24 2007-04-24 Henry Whitfield Secure system for the issuance, acquisition, and redemption of certificates in a transaction network
US7171000B1 (en) 1999-06-10 2007-01-30 Message Secure Corp. Simplified addressing for private communications
US6577642B1 (en) 1999-01-15 2003-06-10 3Com Corporation Method and system for virtual network administration with a data-over cable system
CN1153427C (zh) * 1999-01-26 2004-06-09 松下电器产业株式会社 数据中继处理方法和装置
DE19961151A1 (de) * 1999-01-29 2000-08-03 Ibm Verfahren zum Erstellen und Lesen eines neuen Zertifikatstyps zur Zertifizierung von Schlüsseln
US6600908B1 (en) 1999-02-04 2003-07-29 Hark C. Chan Method and system for broadcasting and receiving audio information and associated audio indexes
GB9905056D0 (en) 1999-03-05 1999-04-28 Hewlett Packard Co Computing apparatus & methods of operating computer apparatus
US7099338B1 (en) 1999-02-27 2006-08-29 3Com Corporation System and method for insuring dynamic host configuration protocol operation by a host connected to a data network
US6778968B1 (en) 1999-03-17 2004-08-17 Vialogy Corp. Method and system for facilitating opportunistic transactions using auto-probes
EP1039741A3 (en) * 1999-03-22 2003-12-10 Eastman Kodak Company Health care system using data authentication
JP2000276445A (ja) * 1999-03-23 2000-10-06 Nec Corp バイオメトリクス識別を用いた認証方法、装置、認証実行機、認証プログラムを記録した記録媒体
US7245707B1 (en) * 1999-03-26 2007-07-17 Chan Hark C Data network based telephone messaging system
US6973444B1 (en) 1999-03-27 2005-12-06 Microsoft Corporation Method for interdependently validating a digital content package and a corresponding digital license
US7383205B1 (en) * 1999-03-27 2008-06-03 Microsoft Corporation Structure of a digital content package
US7286665B1 (en) * 1999-04-06 2007-10-23 Contentguard Holdings, Inc. System and method for transferring the right to decode messages
US7356688B1 (en) * 1999-04-06 2008-04-08 Contentguard Holdings, Inc. System and method for document distribution
WO2000062181A1 (en) * 1999-04-08 2000-10-19 Keith Richard Holbrook Information transmission and collection apparatus and method
AU4370400A (en) * 1999-05-05 2000-11-21 Uroam, Inc. A method and apparatus for accessing a computer using a browser
ATE440333T1 (de) * 1999-05-13 2009-09-15 Ascom Hasler Mailing Sys Inc Technik zur sicheren fern-konfiguration eines systems
US7246244B2 (en) * 1999-05-14 2007-07-17 Fusionarc, Inc. A Delaware Corporation Identity verification method using a central biometric authority
US7499551B1 (en) 1999-05-14 2009-03-03 Dell Products L.P. Public key infrastructure utilizing master key encryption
US6611868B1 (en) 1999-05-21 2003-08-26 3Com Corporation Method and system for automatic link hang up
US6697862B1 (en) 1999-05-21 2004-02-24 3Com Corporation System and method for network address maintenance using dynamic host configuration protocol messages in a data-over-cable system
US6654387B1 (en) 1999-05-21 2003-11-25 3Com Corporation Method for network address table maintenance in a data-over-cable system using a network device registration procedure
US6754622B1 (en) 1999-05-24 2004-06-22 3Com Corporation Method for network address table maintenance in a data-over-cable system using destination reachibility
US6985437B1 (en) 1999-05-25 2006-01-10 3Com Corporation Method for dynamic performance optimization in a data-over-cable system
EP1496654B1 (en) * 1999-05-25 2006-07-12 Lucent Technologies Inc. Method for telecommunications using internet protocol
WO2000074298A1 (en) * 1999-05-26 2000-12-07 Ascom Hasler Mailing Systems, Inc. Technique for split knowledge backup and recovery of a cryptographic key
US6785292B1 (en) 1999-05-28 2004-08-31 3Com Corporation Method for detecting radio frequency impairments in a data-over-cable system
DE19925910B4 (de) * 1999-06-07 2005-04-28 Siemens Ag Verfahren zum Be- oder Verarbeiten von Daten
US20020101998A1 (en) * 1999-06-10 2002-08-01 Chee-Hong Wong Fast escrow delivery
US20020019932A1 (en) * 1999-06-10 2002-02-14 Eng-Whatt Toh Cryptographically secure network
US6988199B2 (en) 2000-07-07 2006-01-17 Message Secure Secure and reliable document delivery
US7707420B1 (en) 1999-06-23 2010-04-27 Research In Motion Limited Public key encryption with digital signature scheme
AU5135400A (en) 1999-06-30 2001-01-22 Walker Digital, Llc Vending machine system and method for encouraging the purchase of profitable items
IL130963A (en) * 1999-07-15 2006-04-10 Nds Ltd Key management for content protection
DE19964198A1 (de) * 1999-07-15 2001-04-12 Erland Wittkoetter Datenverarbeitungsvorrichtung
GB2353682B (en) * 1999-07-15 2004-03-31 Nds Ltd Key management for content protection
KR100315387B1 (ko) * 1999-08-02 2001-11-26 윤금 개인키 및 사용자 인증서 관리 시스템 및 그 관리 방법
EP1208707B1 (en) * 1999-08-12 2014-06-25 Elad Barkan Add-on base station for cellular network expansion
US7373517B1 (en) 1999-08-19 2008-05-13 Visto Corporation System and method for encrypting and decrypting files
US6823456B1 (en) * 1999-08-25 2004-11-23 International Business Machines Corporation System and method for providing trusted services via trusted server agents
US6289455B1 (en) * 1999-09-02 2001-09-11 Crypotography Research, Inc. Method and apparatus for preventing piracy of digital content
ATE453268T1 (de) * 1999-09-07 2010-01-15 Nokia Corp Geortnete bereitstellung von aufgefangenen daten
US7181014B1 (en) 1999-09-10 2007-02-20 Cisco Technology, Inc. Processing method for key exchange among broadcast or multicast groups that provides a more efficient substitute for Diffie-Hellman key exchange
US7103185B1 (en) 1999-12-22 2006-09-05 Cisco Technology, Inc. Method and apparatus for distributing and updating private keys of multicast group managers using directory replication
US7434046B1 (en) 1999-09-10 2008-10-07 Cisco Technology, Inc. Method and apparatus providing secure multicast group communication
US7013389B1 (en) 1999-09-29 2006-03-14 Cisco Technology, Inc. Method and apparatus for creating a secure communication channel among multiple event service nodes
US7260716B1 (en) 1999-09-29 2007-08-21 Cisco Technology, Inc. Method for overcoming the single point of failure of the central group controller in a binary tree group key exchange approach
US6987855B1 (en) 1999-09-10 2006-01-17 Cisco Technology, Inc. Operational optimization of a shared secret Diffie-Hellman key exchange among broadcast or multicast groups
US6684331B1 (en) 1999-12-22 2004-01-27 Cisco Technology, Inc. Method and apparatus for distributing and updating group controllers over a wide area network using a tree structure
US7362973B1 (en) * 1999-09-15 2008-04-22 International Business Machines Corporation Protecting secret data entry from infrared and audio eavesdropping
JP2003510694A (ja) 1999-09-20 2003-03-18 クインタイルズ トランスナショナル コーポレイション 匿名化された健康管理情報を分析するためのシステム及び方法
US7391865B2 (en) 1999-09-20 2008-06-24 Security First Corporation Secure data parser method and system
US7260724B1 (en) 1999-09-20 2007-08-21 Security First Corporation Context sensitive dynamic authentication in a cryptographic system
US9189777B1 (en) * 1999-09-20 2015-11-17 Security First Corporation Electronic commerce with cryptographic authentication
US6853988B1 (en) * 1999-09-20 2005-02-08 Security First Corporation Cryptographic server with provisions for interoperability between cryptographic systems
US6732113B1 (en) * 1999-09-20 2004-05-04 Verispan, L.L.C. System and method for generating de-identified health care data
US7269261B1 (en) * 1999-09-22 2007-09-11 Raytheon Company Key escrow systems
US6553568B1 (en) 1999-09-29 2003-04-22 3Com Corporation Methods and systems for service level agreement enforcement on a data-over cable system
JP4011243B2 (ja) * 1999-10-15 2007-11-21 富士通株式会社 電子原本管理装置および方法
US7461022B1 (en) 1999-10-20 2008-12-02 Yahoo! Inc. Auction redemption system and method
DE69929251T2 (de) * 1999-10-20 2006-07-13 Fujitsu Ltd., Kawasaki Verschlüsselungssystem mit einem schlüssel veränderlicher länge
WO2001029762A2 (en) * 1999-10-20 2001-04-26 Spyrus, Inc. Method and system for an integrated circuit card interface device with multiple modes of operation
KR100586030B1 (ko) * 1999-11-03 2006-06-01 한국전자통신연구원 암호키 복구 정보 관리 방법
US6826690B1 (en) * 1999-11-08 2004-11-30 International Business Machines Corporation Using device certificates for automated authentication of communicating devices
US6823454B1 (en) * 1999-11-08 2004-11-23 International Business Machines Corporation Using device certificates to authenticate servers before automatic address assignment
US7421472B1 (en) 1999-11-19 2008-09-02 Ross Jr Robert C System, method, and computer program product for providing a multi-user e-mail system
US7180889B1 (en) 1999-12-30 2007-02-20 At&T Corp. Personal control of address assignment and greeting options for multiple BRG ports
US6889321B1 (en) * 1999-12-30 2005-05-03 At&T Corp. Protected IP telephony calls using encryption
US6937713B1 (en) 1999-12-30 2005-08-30 At&T Corp. IP call forward profile
US6775267B1 (en) 1999-12-30 2004-08-10 At&T Corp Method for billing IP broadband subscribers
US6826173B1 (en) 1999-12-30 2004-11-30 At&T Corp. Enhanced subscriber IP alerting
US7089211B1 (en) * 2000-01-12 2006-08-08 Cisco Technology, Inc. Directory enabled secure multicast group communications
US7010683B2 (en) * 2000-01-14 2006-03-07 Howlett-Packard Development Company, L.P. Public key validation service
US7340600B1 (en) 2000-01-14 2008-03-04 Hewlett-Packard Development Company, L.P. Authorization infrastructure based on public key cryptography
US7269726B1 (en) 2000-01-14 2007-09-11 Hewlett-Packard Development Company, L.P. Lightweight public key infrastructure employing unsigned certificates
US7020778B1 (en) * 2000-01-21 2006-03-28 Sonera Smarttrust Oy Method for issuing an electronic identity
FR2804561B1 (fr) * 2000-01-31 2002-03-01 France Telecom Procede de communication avec sequestre et recuperation de cle de chiffrement
US6965992B1 (en) 2000-02-24 2005-11-15 3Com Corporation Method and system for network security capable of doing stronger encryption with authorized devices
US20030101346A1 (en) * 2000-02-29 2003-05-29 Barron Austin Kesler Method for notarizing receipt of electronic communications and enabling electronic registered mail; method for verifying identity of account party
US6950809B2 (en) 2000-03-03 2005-09-27 Dun & Bradstreet, Inc. Facilitating a transaction in electronic commerce
EP1134977A1 (en) * 2000-03-06 2001-09-19 Irdeto Access B.V. Method and system for providing copies of scrambled content with unique watermarks, and system for descrambling scrambled content
US20060155731A1 (en) * 2000-03-09 2006-07-13 Pkware, Inc. System and method for manipulating and managing computer archive files
US8230482B2 (en) * 2000-03-09 2012-07-24 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060143714A1 (en) * 2000-03-09 2006-06-29 Pkware, Inc. System and method for manipulating and managing computer archive files
US20050015608A1 (en) 2003-07-16 2005-01-20 Pkware, Inc. Method for strongly encrypting .ZIP files
US6879988B2 (en) 2000-03-09 2005-04-12 Pkware System and method for manipulating and managing computer archive files
US7844579B2 (en) 2000-03-09 2010-11-30 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060143252A1 (en) * 2000-03-09 2006-06-29 Pkware, Inc. System and method for manipulating and managing computer archive files
US8959582B2 (en) 2000-03-09 2015-02-17 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060173848A1 (en) * 2000-03-09 2006-08-03 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060143250A1 (en) * 2000-03-09 2006-06-29 Pkware, Inc. System and method for manipulating and managing computer archive files
US6895501B1 (en) * 2000-03-13 2005-05-17 Wrq, Inc. Method and apparatus for distributing, interpreting, and storing heterogeneous certificates in a homogenous public key infrastructure
US7089580B1 (en) 2000-03-29 2006-08-08 3Com Corporation Method for improved cable modem ranging in a data-over-cable system
US20040186996A1 (en) * 2000-03-29 2004-09-23 Gibbs Benjamin K. Unique digital signature
US7376835B2 (en) * 2000-04-25 2008-05-20 Secure Data In Motion, Inc. Implementing nonrepudiation and audit using authentication assertions and key servers
US7277549B2 (en) * 2000-04-25 2007-10-02 Secure Data In Motion, Inc. System for implementing business processes using key server events
US7325127B2 (en) * 2000-04-25 2008-01-29 Secure Data In Motion, Inc. Security server system
US6584564B2 (en) * 2000-04-25 2003-06-24 Sigaba Corporation Secure e-mail system
US7237114B1 (en) 2000-04-26 2007-06-26 Pronvest, Inc. Method and system for signing and authenticating electronic documents
US6804262B1 (en) 2000-04-28 2004-10-12 3Com Corporation Method and apparatus for channel determination through power measurements
US7308718B1 (en) * 2000-05-09 2007-12-11 Neopost Technologies Technique for secure remote configuration of a system
US7640580B1 (en) 2000-05-17 2009-12-29 F5 Networks, Inc. Method and apparatus for accessing a computer behind a firewall
US7069443B2 (en) * 2000-06-06 2006-06-27 Ingeo Systems, Inc. Creating and verifying electronic documents
WO2001095125A1 (en) * 2000-06-06 2001-12-13 Ingeo Systems, Inc. Processing electronic documents with embedded digital signatures
FR2810138B1 (fr) * 2000-06-08 2005-02-11 Bull Cp8 Procede de stockage securise d'une donnee sensible dans une memoire d'un systeme embarque a puce electronique, notamment d'une carte a puce, et systeme embarque mettant en oeuvre le procede
EP1292872B2 (en) * 2000-06-09 2018-12-19 Certicom Corp. A method for the application of implicit signature schemes
US7493486B1 (en) * 2000-06-09 2009-02-17 Verizon Laboratories, Inc. Method and apparatus for supporting cryptographic-related activities in a public key infrastructure
US20040073617A1 (en) * 2000-06-19 2004-04-15 Milliken Walter Clark Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail
US6944881B1 (en) 2000-06-19 2005-09-13 3Com Corporation Method for using an initial maintenance opportunity for non-contention ranging
US6891953B1 (en) * 2000-06-27 2005-05-10 Microsoft Corporation Method and system for binding enhanced software features to a persona
US6941457B1 (en) 2000-06-30 2005-09-06 Cisco Technology, Inc. Establishing a new shared secret key over a broadcast channel for a multicast group based on an old shared secret key
WO2002005481A1 (en) * 2000-07-06 2002-01-17 Hitae Lee Three-way encryption/decryption system
US7251728B2 (en) 2000-07-07 2007-07-31 Message Secure Corporation Secure and reliable document delivery using routing lists
US6816500B1 (en) 2000-07-10 2004-11-09 3Com Corporation Apparatus, method and system for multimedia access network channel management
US6820201B1 (en) * 2000-08-04 2004-11-16 Sri International System and method using information-based indicia for securing and authenticating transactions
US7010691B2 (en) * 2000-08-04 2006-03-07 First Data Corporation ABDS system utilizing security information in authenticating entity access
AU2008203525B2 (en) * 2000-08-04 2011-11-10 First Data Corporation Linking public key of device to information during manufacturing
US7096354B2 (en) * 2000-08-04 2006-08-22 First Data Corporation Central key authority database in an ABDS system
US6983368B2 (en) * 2000-08-04 2006-01-03 First Data Corporation Linking public key of device to information during manufacture
JP2004506361A (ja) 2000-08-04 2004-02-26 ファースト　データ　コーポレイション デバイスの検証ステータスを提供することによる電子通信におけるエンティティ認証
US6978369B2 (en) * 2000-08-04 2005-12-20 First Data Corporation Person-centric account-based digital signature system
US6789189B2 (en) * 2000-08-04 2004-09-07 First Data Corporation Managing account database in ABDS system
US7082533B2 (en) * 2000-08-04 2006-07-25 First Data Corporation Gauging risk in electronic communications regarding accounts in ABDS system
US7558965B2 (en) 2000-08-04 2009-07-07 First Data Corporation Entity authentication in electronic communications by providing verification status of device
WO2002013040A1 (en) * 2000-08-09 2002-02-14 Keith Richard Holbrook Information transmission and collection apparatus and method
WO2002015081A1 (en) * 2000-08-14 2002-02-21 Yahoo! Inc. Offline-online incentive points system and method
GB0020371D0 (en) * 2000-08-18 2000-10-04 Hewlett Packard Co Apparatus and method for establishing trust
US8307098B1 (en) * 2000-08-29 2012-11-06 Lenovo (Singapore) Pte. Ltd. System, method, and program for managing a user key used to sign a message for a data processing system
US7225231B2 (en) * 2000-09-20 2007-05-29 Visto Corporation System and method for transmitting workspace elements across a network
EP2306259B1 (en) 2000-09-21 2015-05-27 BlackBerry Limited Software code signing system and method
US7107326B1 (en) 2000-10-13 2006-09-12 3Com Corporation Method and system for integrating IP address reservations with policy provisioning
US20020048372A1 (en) * 2000-10-19 2002-04-25 Eng-Whatt Toh Universal signature object for digital data
US20030021417A1 (en) * 2000-10-20 2003-01-30 Ognjen Vasic Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US6789193B1 (en) * 2000-10-27 2004-09-07 Pitney Bowes Inc. Method and system for authenticating a network user
JP2002202719A (ja) * 2000-11-06 2002-07-19 Sony Corp 暗号化装置及び方法、復号装置及び方法、並びに記憶媒体
JP2004514977A (ja) * 2000-11-20 2004-05-20 シャンテ　コーポレーション システム、方法、およびマルチユーザ電子メールシステム用のコンピュータプログラム製品
US7068597B1 (en) 2000-11-27 2006-06-27 3Com Corporation System and method for automatic load balancing in a data-over-cable network
US6948184B1 (en) 2000-11-30 2005-09-20 3Com Corporation System and method for calibrating power level during initial ranging of a network client device
US6940874B2 (en) * 2000-11-30 2005-09-06 3Com Corporation Method for reducing interference from initializing network devices in a data-over-cable system
US20020067833A1 (en) * 2000-12-05 2002-06-06 Han Ching-Chih (Jason) Method and apparatus for providing conditional access to the source code of a program
US20080214300A1 (en) * 2000-12-07 2008-09-04 Igt Methods for electronic data security and program authentication
KR100377019B1 (ko) * 2000-12-09 2003-03-26 이임영 블라인드 기술을 이용한 신원위탁방법
US7149310B2 (en) * 2000-12-19 2006-12-12 Tricipher, Inc. Method and system for authorizing generation of asymmetric crypto-keys
US6934840B2 (en) * 2000-12-21 2005-08-23 International Business Machines Corporation Composite keystore facility apparatus and method therefor
US20030084020A1 (en) * 2000-12-22 2003-05-01 Li Shu Distributed fault tolerant and secure storage
US6988196B2 (en) * 2000-12-22 2006-01-17 Lenovo (Singapore) Pte Ltd Computer system and method for generating a digital certificate
US6948065B2 (en) 2000-12-27 2005-09-20 Intel Corporation Platform and method for securely transmitting an authorization secret
JP4284867B2 (ja) * 2001-01-18 2009-06-24 株式会社日立製作所 標準モデル上で適応的選択暗号文攻撃に対して安全な公開鍵暗号方法
US6952428B1 (en) 2001-01-26 2005-10-04 3Com Corporation System and method for a specialized dynamic host configuration protocol proxy in a data-over-cable network
US6996842B2 (en) * 2001-01-30 2006-02-07 Intel Corporation Processing internet protocol security traffic
AU742639B3 (en) 2001-02-15 2002-01-10 Ewise Systems Pty Limited Secure network access
US6895104B2 (en) 2001-02-16 2005-05-17 Sac Technologies, Inc. Image identification system
US7073055B1 (en) 2001-02-22 2006-07-04 3Com Corporation System and method for providing distributed and dynamic network services for remote access server users
US7222255B1 (en) 2001-02-28 2007-05-22 3Com Corporation System and method for network performance testing
US20020129261A1 (en) * 2001-03-08 2002-09-12 Cromer Daryl Carvis Apparatus and method for encrypting and decrypting data recorded on portable cryptographic tokens
US7711122B2 (en) * 2001-03-09 2010-05-04 Arcot Systems, Inc. Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys
US7181017B1 (en) 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
EP1307000A4 (en) * 2001-03-29 2007-07-04 Sony Corp INFORMATION PROCESSING APPARATUS
GB2374497B (en) * 2001-04-03 2003-03-12 Ericsson Telefon Ab L M Facilitating legal interception of IP connections
US7603703B2 (en) * 2001-04-12 2009-10-13 International Business Machines Corporation Method and system for controlled distribution of application code and content data within a computer network
EP1391073B8 (en) * 2001-05-01 2018-09-05 OneSpan International GmbH Method and system for increasing security of a secure connection
ATE329426T1 (de) * 2001-05-23 2006-06-15 Daniel Buettiker Verfahren und datenträger zur eintragung von benutzern einer public-key-infrastruktur und eintragungssystem
US7103606B2 (en) * 2001-06-18 2006-09-05 International Business Machines Corporation Method and apparatus for removing information from a server
US20020191020A1 (en) * 2001-06-18 2002-12-19 International Business Machines Corporation Method and apparatus for removing confindential information from a history
US20020191032A1 (en) * 2001-06-18 2002-12-19 International Business Machines Corporation Method and apparatus for viewing and managing information in a history
US6834795B1 (en) * 2001-06-29 2004-12-28 Sun Microsystems, Inc. Secure user authentication to computing resource via smart card
FI112904B (fi) * 2001-06-29 2004-01-30 Nokia Corp Menetelmä suojata elektroninen laite ja elektroninen laite
US7257844B2 (en) 2001-07-31 2007-08-14 Marvell International Ltd. System and method for enhanced piracy protection in a wireless personal communication device
EP1414183B1 (en) 2001-08-01 2012-11-14 Panasonic Corporation Encrypted data delivery system
US20040128508A1 (en) * 2001-08-06 2004-07-01 Wheeler Lynn Henry Method and apparatus for access authentication entity
US7088678B1 (en) 2001-08-27 2006-08-08 3Com Corporation System and method for traffic shaping based on generalized congestion and flow control
US7313828B2 (en) * 2001-09-04 2007-12-25 Nokia Corporation Method and apparatus for protecting software against unauthorized use
US7779267B2 (en) * 2001-09-04 2010-08-17 Hewlett-Packard Development Company, L.P. Method and apparatus for using a secret in a distributed computing system
FR2829644A1 (fr) * 2001-09-10 2003-03-14 St Microelectronics Sa Procede securise de transmission de donnees multimedia
US20030051160A1 (en) * 2001-09-11 2003-03-13 Selkirk Stephen S. Anti-piracy firmware update
JP4969745B2 (ja) * 2001-09-17 2012-07-04 株式会社東芝 公開鍵基盤システム
KR20030028618A (ko) * 2001-09-20 2003-04-10 (주) 엘지텔레콤 네트워크를 이용한 인증서 발급 서비스 방법
WO2003030447A2 (en) 2001-09-27 2003-04-10 Matsushita Electric Industrial Co., Ltd. An encryption device, a decrypting device, a secret key generation device,a copyright protection system and a cipher communication device
GB0123453D0 (en) * 2001-09-28 2001-11-21 Ncipher Corp Ltd Time stamping device
US7207060B2 (en) 2001-10-18 2007-04-17 Nokia Corporation Method, system and computer program product for secure ticketing in a communications device
US7178041B2 (en) 2001-10-18 2007-02-13 Nokia Corporation Method, system and computer program product for a trusted counter in an external security element for securing a personal communication device
US20030076957A1 (en) * 2001-10-18 2003-04-24 Nadarajah Asokan Method, system and computer program product for integrity-protected storage in a personal communication device
US7085306B1 (en) 2001-10-30 2006-08-01 3Com Corporation System and method for a multi-frequency upstream channel in a computer network
JP4055393B2 (ja) * 2001-10-30 2008-03-05 ソニー株式会社 データ処理装置およびその方法とプログラム
US6973191B2 (en) * 2001-11-02 2005-12-06 Activcard System and method for generating symmetric keys within a personal security device having minimal trust relationships
US6785381B2 (en) * 2001-11-27 2004-08-31 Siemens Information And Communication Networks, Inc. Telephone having improved hands free operation audio quality and method of operation thereof
US7334125B1 (en) 2001-11-27 2008-02-19 Cisco Technology, Inc. Facilitating secure communications among multicast nodes in a telecommunications network
US7007040B1 (en) 2001-12-04 2006-02-28 General Dynamics C4 Systems, Inc. Method and apparatus for storing and updating information in a multi-cast system
WO2003049357A2 (en) * 2001-12-07 2003-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Lawful interception of end-to-end encrypted data traffic
US7171493B2 (en) * 2001-12-19 2007-01-30 The Charles Stark Draper Laboratory Camouflage of network traffic to resist attack
US7225161B2 (en) * 2001-12-21 2007-05-29 Schlumberger Omnes, Inc. Method and system for initializing a key management system
US7072337B1 (en) 2002-01-25 2006-07-04 3Com Corporation System and method for resolving network addresses for network devices on distributed network subnets
US20030145025A1 (en) * 2002-01-31 2003-07-31 Allred Rustin W. Method of designing families of boost and cut filters, including treble and bass controls and graphic equalizers
US7818792B2 (en) * 2002-02-04 2010-10-19 General Instrument Corporation Method and system for providing third party authentication of authorization
US7146009B2 (en) * 2002-02-05 2006-12-05 Surety, Llc Secure electronic messaging system requiring key retrieval for deriving decryption keys
US7415440B1 (en) * 2002-02-22 2008-08-19 Entriq, Inc. Method and system to provide secure key selection using a secure device in a watercrypting environment
US7251635B2 (en) * 2002-02-25 2007-07-31 Schlumberger Omnes, Inc. Method and apparatus for managing a key management system
US7228417B2 (en) 2002-02-26 2007-06-05 America Online, Inc. Simple secure login with multiple-authentication providers
US7308579B2 (en) * 2002-03-15 2007-12-11 Noel Abela Method and system for internationally providing trusted universal identification over a global communications network
US7627753B2 (en) * 2002-03-19 2009-12-01 Microsoft Corporation Secure digital data format and code enforced policy
GB2387301B (en) * 2002-04-02 2005-02-09 Clive Neil Galley Private-key cryptosystem and other applications
US20030196096A1 (en) * 2002-04-12 2003-10-16 Sutton James A. Microcode patch authentication
US7822495B2 (en) * 2002-04-15 2010-10-26 Fisher-Rosemount Systems, Inc. Custom function blocks for use with process control systems
US7475248B2 (en) 2002-04-29 2009-01-06 International Business Machines Corporation Enhanced message security
US7007159B2 (en) * 2002-05-10 2006-02-28 Intel Corporation System and method for loading and integrating a firmware extension onto executable base system firmware during initialization
US20030212889A1 (en) * 2002-05-13 2003-11-13 Khieu Andrew K. Method and system for exchanging data over networks using public key encryption
AU2003247364A1 (en) * 2002-05-15 2003-12-02 Bio-Key International, Inc. Match template protection within biometric security systems
US7340770B2 (en) * 2002-05-15 2008-03-04 Check Point Software Technologies, Inc. System and methodology for providing community-based security policies
US7096254B2 (en) * 2002-05-30 2006-08-22 International Business Machines Corporation Electronic mail distribution network implementation for safeguarding sender's address book covering addressee aliases with minimum interference with normal electronic mail transmission
US7596531B2 (en) * 2002-06-05 2009-09-29 Sun Microsystems, Inc. Method and apparatus for protecting against side channel attacks against personal identification numbers
US7162456B2 (en) * 2002-06-05 2007-01-09 Sun Microsystems, Inc. Method for private personal identification number management
US7167843B2 (en) 2002-06-05 2007-01-23 Sun Microsystems, Inc. Apparatus for private personal identification number management
US20030233562A1 (en) * 2002-06-12 2003-12-18 Sachin Chheda Data-protection circuit and method
KR100466827B1 (ko) * 2002-06-14 2005-01-17 이임영 키 복구를 지원하는 신원 위탁 방법
US7352867B2 (en) * 2002-07-10 2008-04-01 General Instrument Corporation Method of preventing unauthorized distribution and use of electronic keys using a key seed
AU2003261234A1 (en) * 2002-07-25 2004-02-16 Bio-Key International, Inc. Trusted biometric device
US6931133B2 (en) * 2002-09-03 2005-08-16 Verisign, Inc. Method and system of securely escrowing private keys in a public key infrastructure
US7900051B2 (en) * 2002-09-10 2011-03-01 Stmicroelectronics S.A. Secure multimedia data transmission method
US8083585B2 (en) 2002-09-10 2011-12-27 Igt Apparatus and method for copying gaming machine configuration settings
EP1540880B1 (de) * 2002-09-11 2006-03-08 Giesecke & Devrient GmbH Geschützte kryptographische berechnung
US20040054901A1 (en) * 2002-09-17 2004-03-18 Microsoft Corporation Creating and verifying a sequence of consecutive data
US7548621B1 (en) 2002-09-26 2009-06-16 Ncr Corporation System and method for securing a base derivation key for use in injection of derived unique key per transaction devices
US7426382B2 (en) * 2002-10-09 2008-09-16 Motorola, Inc. Contact validation and trusted contact updating in mobile wireless communications devices
US7574607B1 (en) * 2002-10-29 2009-08-11 Zix Corporation Secure pipeline processing
KR100502066B1 (ko) * 2002-10-31 2005-07-25 한국전자통신연구원 비밀키 관리 시스템 및 방법
US7207067B2 (en) * 2002-11-12 2007-04-17 Aol Llc Enforcing data protection legislation in Web data services
US7131003B2 (en) 2003-02-20 2006-10-31 America Online, Inc. Secure instant messaging system
FR2849248B1 (fr) * 2002-12-20 2005-06-24 Oberthur Card Syst Sa Entite electronique securisee permettant une certification du temps
AU2003300058A1 (en) * 2003-01-07 2004-08-10 Qualcomm Incorporated System, apparatus and method for replacing a cryptographic key
US7640427B2 (en) * 2003-01-07 2009-12-29 Pgp Corporation System and method for secure electronic communication in a partially keyless environment
US7562229B2 (en) * 2003-01-23 2009-07-14 Hewlett-Packard Development Company, L.P. Codeword-based auditing of computer systems and methods therefor
US9818136B1 (en) 2003-02-05 2017-11-14 Steven M. Hoffberg System and method for determining contingent relevance
US7779482B1 (en) * 2003-02-07 2010-08-17 iGware Inc Delivery of license information using a short messaging system protocol in a closed content distribution system
US8131649B2 (en) 2003-02-07 2012-03-06 Igware, Inc. Static-or-dynamic and limited-or-unlimited content rights
US20100017627A1 (en) 2003-02-07 2010-01-21 Broadon Communications Corp. Ensuring authenticity in a closed content distribution system
KR100670723B1 (ko) * 2003-02-21 2007-01-19 리서치 인 모션 리미티드 전자 장치들의 다중-레벨 제어 시스템 및 방법
US7370212B2 (en) 2003-02-25 2008-05-06 Microsoft Corporation Issuing a publisher use license off-line in a digital rights management (DRM) system
WO2004084029A2 (en) * 2003-03-14 2004-09-30 Citibank, N.A. Method and system of transaction security
US7490348B1 (en) 2003-03-17 2009-02-10 Harris Technology, Llc Wireless network having multiple communication allowances
US20040190721A1 (en) * 2003-03-24 2004-09-30 Microsoft Corporation Renewable conditional access system
US7739583B2 (en) 2003-03-31 2010-06-15 Ricoh Company, Ltd. Multimedia document sharing method and apparatus
US7536638B2 (en) 2003-03-31 2009-05-19 Ricoh Co., Ltd. Action stickers for identifying and processing stored documents
US7757162B2 (en) 2003-03-31 2010-07-13 Ricoh Co. Ltd. Document collection manipulation
US7703002B2 (en) 2003-03-31 2010-04-20 Ricoh Company, Ltd. Method and apparatus for composing multimedia documents
US7509569B2 (en) * 2003-03-31 2009-03-24 Ricoh Co., Ltd. Action stickers for nested collections
US20040199768A1 (en) * 2003-04-04 2004-10-07 Nail Robert A. System and method for enabling enterprise application security
US7836493B2 (en) 2003-04-24 2010-11-16 Attachmate Corporation Proxy server security token authorization
US6834347B2 (en) 2003-04-29 2004-12-21 International Business Machines Corporation Target self-security for upgrades for an embedded device
CA2525398C (en) 2003-05-13 2014-03-11 Corestreet, Ltd. Efficient and secure data currentness systems
EP1636682A4 (en) * 2003-06-24 2009-04-29 Corestreet Ltd ACCESS CONTROL
US8214884B2 (en) * 2003-06-27 2012-07-03 Attachmate Corporation Computer-based dynamic secure non-cached delivery of security credentials such as digitally signed certificates or keys
KR101000918B1 (ko) * 2003-09-01 2010-12-13 삼성전자주식회사 공개 키/개인 키 쌍을 재사용하는 장치 및 방법
JP4583833B2 (ja) * 2003-09-12 2010-11-17 株式会社リコー 通信装置、通信システム、通信方法及びプログラム
US7290278B2 (en) 2003-10-02 2007-10-30 Aol Llc, A Delaware Limited Liability Company Identity based service system
US7558954B2 (en) * 2003-10-31 2009-07-07 Hewlett-Packard Development Company, L.P. Method and apparatus for ensuring the integrity of data
CA2544273C (en) * 2003-11-19 2015-01-13 Corestreet, Ltd. Distributed delegated path discovery and validation
US7698557B2 (en) * 2003-12-22 2010-04-13 Guardtime As System and method for generating a digital certificate
US7523315B2 (en) * 2003-12-22 2009-04-21 Ingeo Systems, Llc Method and process for creating an electronically signed document
US8139770B2 (en) * 2003-12-23 2012-03-20 Wells Fargo Bank, N.A. Cryptographic key backup and escrow system
ES2385824T3 (es) * 2003-12-30 2012-08-01 Telecom Italia S.P.A. Procedimiento y sistema de protección de datos, red de comunicaciones relacionada y producto de programa informático
JP2005196412A (ja) * 2004-01-06 2005-07-21 Sony Corp データ通信装置及びデータ通信装置のメモリ管理方法
CA2551819C (en) * 2004-01-09 2015-02-24 Corestreet, Ltd. Signature-efficient real time credentials for ocsp and distributed ocsp
JP4434969B2 (ja) 2004-01-21 2010-03-17 株式会社東芝 コンテンツ提供側システム、ユーザ側システム、追跡システム、装置、方法及びプログラム
US20050172229A1 (en) * 2004-01-29 2005-08-04 Arcot Systems, Inc. Browser user-interface security application
JP4556103B2 (ja) * 2004-02-24 2010-10-06 ソニー株式会社 暗号化装置及び暗号化方法
KR101254209B1 (ko) * 2004-03-22 2013-04-23 삼성전자주식회사 디바이스와 휴대용 저장장치간에 권리 객체를 이동,복사하는 방법 및 장치
NZ549544A (en) * 2004-03-22 2008-03-28 Samsung Electronics Co Ltd Method and apparatus for digital rights management using certificate revocation list
CN100512098C (zh) * 2004-03-26 2009-07-08 上海山丽信息安全有限公司 具有指纹限制的机密文件访问授权系统
US20060242406A1 (en) 2005-04-22 2006-10-26 Microsoft Corporation Protected computing environment
ATE388570T1 (de) * 2004-05-19 2008-03-15 Alcatel Lucent Verfahren zur bereitstellung eines signierungsschlüssels zur digitalen signierung, überprüfung oder verschlüsselung von daten
US7644409B2 (en) * 2004-06-04 2010-01-05 Sun Microsystems, Inc. Techniques for accessing a shared resource using an improved synchronization mechanism
US7594234B1 (en) * 2004-06-04 2009-09-22 Sun Microsystems, Inc. Adaptive spin-then-block mutual exclusion in multi-threaded processing
WO2006002068A2 (en) * 2004-06-15 2006-01-05 Passmark Security, Inc. Method and apparatus for making accessible a set of services to users
US7421589B2 (en) * 2004-07-21 2008-09-02 Beachhead Solutions, Inc. System and method for lost data destruction of electronic data stored on a portable electronic device using a security interval
CN100409138C (zh) * 2004-07-21 2008-08-06 京瓷美达株式会社 密码验证装置及验证方法
US7475397B1 (en) 2004-07-28 2009-01-06 Sun Microsystems, Inc. Methods and apparatus for providing a remote serialization guarantee
WO2006018874A1 (ja) * 2004-08-19 2006-02-23 Mitsubishi Denki Kabushiki Kaisha 管理サービス装置、バックアップサービス装置、通信端末装置及び記憶媒体
US8284942B2 (en) * 2004-08-24 2012-10-09 Microsoft Corporation Persisting private/public key pairs in password-encrypted files for transportation to local cryptographic store
CN101015165B (zh) 2004-08-26 2010-05-05 富士通株式会社 内容管理方法及装置
JP2006139747A (ja) * 2004-08-30 2006-06-01 Kddi Corp 通信システムおよび安全性保証装置
US7433847B2 (en) * 2004-09-22 2008-10-07 Pitney Bowes Inc. System and method for manufacturing and securing transport of postage printing devices
US20060075254A1 (en) * 2004-09-27 2006-04-06 Cisco Technology, Inc. (A California Corporation) Smart card functionality from a security co-processor and symmetric key in ROM
US7636852B1 (en) * 2004-10-07 2009-12-22 Sprint Communications Company L.P. Call center dashboard
US9558341B1 (en) 2004-10-07 2017-01-31 Sprint Communications Company L.P. Integrated user profile administration tool
JP4725070B2 (ja) * 2004-10-13 2011-07-13 パナソニック株式会社 正規コンテンツ確認方法、コンテンツ送受信システム、送信機、および受信機
US8347078B2 (en) 2004-10-18 2013-01-01 Microsoft Corporation Device certificate individualization
TW200635324A (en) * 2004-10-25 2006-10-01 Matsushita Electric Ind Co Ltd Authentication method
CN101375284B (zh) 2004-10-25 2012-02-22 安全第一公司 安全数据分析方法和系统
US7205882B2 (en) 2004-11-10 2007-04-17 Corestreet, Ltd. Actuating a security system using a wireless device
WO2006051404A2 (en) * 2004-11-11 2006-05-18 Certicom Corp. Secure interface for versatile key derivation function support
US8176564B2 (en) 2004-11-15 2012-05-08 Microsoft Corporation Special PC mode entered upon detection of undesired state
US8336085B2 (en) 2004-11-15 2012-12-18 Microsoft Corporation Tuning product policy using observed evidence of customer behavior
US8464348B2 (en) * 2004-11-15 2013-06-11 Microsoft Corporation Isolated computing environment anchored into CPU and motherboard
US7457960B2 (en) * 2004-11-30 2008-11-25 Analog Devices, Inc. Programmable processor supporting secure mode
US20060129821A1 (en) * 2004-12-13 2006-06-15 Microsoft Corporation Believably trustworthy enforcement of privacy enhancing technologies in data processing
US20080288786A1 (en) * 2004-12-20 2008-11-20 Michael Stephen Fiske System with access keys
GB0428049D0 (en) * 2004-12-22 2005-01-26 Carnall Murat Improvements to call management in a telecommunications system
US7933840B2 (en) * 2004-12-30 2011-04-26 Topaz Systems, Inc. Electronic signature security system
US7490239B2 (en) * 2005-01-07 2009-02-10 First Data Corporation Facilitating digital signature based on ephemeral private key
US20060156013A1 (en) * 2005-01-07 2006-07-13 Beeson Curtis L Digital signature software using ephemeral private key and system
US7593527B2 (en) * 2005-01-07 2009-09-22 First Data Corporation Providing digital signature and public key based on shared knowledge
US7693277B2 (en) * 2005-01-07 2010-04-06 First Data Corporation Generating digital signatures using ephemeral cryptographic key
US7869593B2 (en) 2005-01-07 2011-01-11 First Data Corporation Software for providing based on shared knowledge public keys having same private key
US20060153369A1 (en) * 2005-01-07 2006-07-13 Beeson Curtis L Providing cryptographic key based on user input data
US20060153370A1 (en) * 2005-01-07 2006-07-13 Beeson Curtis L Generating public-private key pair based on user input data
US20060153364A1 (en) * 2005-01-07 2006-07-13 Beeson Curtis L Asymmetric key cryptosystem based on shared knowledge
US7936869B2 (en) * 2005-01-07 2011-05-03 First Data Corporation Verifying digital signature based on shared knowledge
JP4768752B2 (ja) * 2005-01-12 2011-09-07 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー 無線周波数識別タグセキュリティシステム
US8943310B2 (en) * 2005-01-25 2015-01-27 Cisco Technology, Inc. System and method for obtaining a digital certificate for an endpoint
US8312263B2 (en) * 2005-01-25 2012-11-13 Cisco Technology, Inc. System and method for installing trust anchors in an endpoint
DE102005009852B3 (de) * 2005-03-03 2006-06-29 Siemens Ag Einrichtung zur Aufnahme und Verwaltung medizinischer Bilddaten sowie zugehöriges Verfahren
US8438645B2 (en) 2005-04-27 2013-05-07 Microsoft Corporation Secure clock with grace periods
US8725646B2 (en) 2005-04-15 2014-05-13 Microsoft Corporation Output protection levels
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
US9363481B2 (en) 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US8175277B2 (en) 2005-04-28 2012-05-08 Cisco Technology, Inc. Intercepting a communication session in a telecommunication network
US20060265758A1 (en) 2005-05-20 2006-11-23 Microsoft Corporation Extensible media rights
JP4121134B2 (ja) * 2005-05-31 2008-07-23 インターナショナル・ビジネス・マシーンズ・コーポレーション プログラム、分類方法およびシステム
US8353046B2 (en) 2005-06-08 2013-01-08 Microsoft Corporation System and method for delivery of a modular operating system
US8028329B2 (en) * 2005-06-13 2011-09-27 Iamsecureonline, Inc. Proxy authentication network
US8295492B2 (en) * 2005-06-27 2012-10-23 Wells Fargo Bank, N.A. Automated key management system
US7836306B2 (en) * 2005-06-29 2010-11-16 Microsoft Corporation Establishing secure mutual trust using an insecure password
US7596225B2 (en) * 2005-06-30 2009-09-29 Alcatl-Lucent Usa Inc. Method for refreshing a pairwise master key
US10021062B2 (en) * 2005-07-01 2018-07-10 Cirius Messaging Inc. Secure electronic mail system
US7730142B2 (en) * 2005-07-01 2010-06-01 0733660 B.C. Ltd. Electronic mail system with functionality to include both private and public messages in a communication
US8438115B2 (en) * 2005-09-23 2013-05-07 Pitney Bowes Inc. Method of securing postage data records in a postage printing device
US7885412B2 (en) * 2005-09-29 2011-02-08 International Business Machines Corporation Pre-generation of generic session keys for use in communicating within communications environments
US8340289B2 (en) 2005-09-29 2012-12-25 Research In Motion Limited System and method for providing an indication of randomness quality of random number data generated by a random data service
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US9118754B2 (en) * 2005-10-18 2015-08-25 Robert H. Nagel System and method for providing a public/private telephone number system
US8260908B2 (en) * 2005-11-16 2012-09-04 Cisco Technologies, Inc. Techniques for sequencing system log messages
CN105978683A (zh) 2005-11-18 2016-09-28 安全第公司 安全数据解析方法和系统
US20070255951A1 (en) * 2005-11-21 2007-11-01 Amiram Grynberg Token Based Multi-protocol Authentication System and Methods
KR100652017B1 (ko) * 2005-12-08 2006-12-01 한국전자통신연구원 물리보안공격에 대한 닥시스 케이블 모뎀의 보안 방법
US8989390B2 (en) * 2005-12-12 2015-03-24 Qualcomm Incorporated Certify and split system and method for replacing cryptographic keys
US8230487B2 (en) 2005-12-21 2012-07-24 International Business Machines Corporation Method and system for controlling access to a secondary system
JP2007172294A (ja) * 2005-12-22 2007-07-05 Hitachi Ltd 利用者の認証機能を備えた情報処理装置
US7499552B2 (en) * 2006-01-11 2009-03-03 International Business Machines Corporation Cipher method and system for verifying a decryption of an encrypted user data key
RU2008135353A (ru) * 2006-01-30 2010-03-10 Конинклейке Филипс Электроникс Н.В. (Nl) Поиск водяного знака в сигнале данных
US20070179903A1 (en) * 2006-01-30 2007-08-02 Microsoft Corporation Identity theft mitigation
US20070223685A1 (en) * 2006-02-06 2007-09-27 David Boubion Secure system and method of providing same
DE102006012311A1 (de) * 2006-03-17 2007-09-20 Deutsche Telekom Ag Verfahren und Vorrichtung zur Pseudonymisierung von digitalen Daten
US9860055B2 (en) * 2006-03-22 2018-01-02 Synopsys, Inc. Flexible architecture for processing of large numbers and method therefor
US20070255823A1 (en) * 2006-05-01 2007-11-01 International Business Machines Corporation Method for low-overhead message tracking in a distributed messaging system
WO2007130554A2 (en) 2006-05-02 2007-11-15 Broadon Communications Corp. Content management system and method
US7703673B2 (en) 2006-05-25 2010-04-27 Buchheit Brian K Web based conversion of non-negotiable credits associated with an entity to entity independent negotiable funds
US9704174B1 (en) 2006-05-25 2017-07-11 Sean I. Mcghie Conversion of loyalty program points to commerce partner points per terms of a mutual agreement
US8684265B1 (en) 2006-05-25 2014-04-01 Sean I. Mcghie Rewards program website permitting conversion/transfer of non-negotiable credits to entity independent funds
US8668146B1 (en) 2006-05-25 2014-03-11 Sean I. Mcghie Rewards program with payment artifact permitting conversion/transfer of non-negotiable credits to entity independent funds
US10062062B1 (en) 2006-05-25 2018-08-28 Jbshbm, Llc Automated teller machine (ATM) providing money for loyalty points
CA2653778C (en) * 2006-06-01 2013-03-26 Exaflop Llc Data center uninterruptible power distribution architecture
CN101502192B (zh) * 2006-06-01 2012-06-20 埃克弗洛普公司 控制的热空气捕获
CN101501599B (zh) 2006-06-01 2011-12-21 谷歌公司 模块化计算环境
US8006298B1 (en) 2006-07-11 2011-08-23 Sprint Communications Company L.P. Fraud detection system and method
US20080271001A1 (en) * 2006-09-11 2008-10-30 Yo Nonomura Method of generating program, information processing device and microcomputer
US7870379B2 (en) * 2006-10-10 2011-01-11 Exaflop Llc Updating a power supply microcontroller
EP2084591B1 (en) * 2006-10-10 2019-09-11 Google LLC Updating a power supply microcontroller
US7624276B2 (en) 2006-10-16 2009-11-24 Broadon Communications Corp. Secure device authentication system and method
US8200960B2 (en) * 2006-10-20 2012-06-12 Oracle America, Inc. Tracking of resource utilization during cryptographic transformations
JP4304300B2 (ja) * 2006-11-01 2009-07-29 日本電気株式会社 ユーザ装置、サーバ、アップグレードサービスシステム、その方法およびプログラム
WO2008053471A1 (en) * 2006-11-02 2008-05-08 Nds Limited Privacy-aware content protection system
CN103188081A (zh) 2006-11-07 2013-07-03 安全第一公司 用于分发数据和保护数据安全的系统和方法
US7578346B2 (en) * 2006-11-08 2009-08-25 Schlumberger Technology Corporation Method of plugging fractured formation
US9141819B2 (en) * 2006-11-08 2015-09-22 International Business Machines Corporation Encrypted tape access control via challenge-response protocol
US7613915B2 (en) 2006-11-09 2009-11-03 BroadOn Communications Corp Method for programming on-chip non-volatile memory in a secure processor, and a device so programmed
US8116456B2 (en) * 2006-11-28 2012-02-14 Oracle International Corporation Techniques for managing heterogeneous key stores
GB2446199A (en) 2006-12-01 2008-08-06 David Irvine Secure, decentralised and anonymous peer-to-peer network
EP2482218A3 (en) 2006-12-05 2012-10-31 Security First Corporation Improved storage backup method using a secure data parser
US8135135B2 (en) * 2006-12-08 2012-03-13 Microsoft Corporation Secure data protection during disasters
US8015039B2 (en) * 2006-12-14 2011-09-06 Sap Ag Enterprise verification and certification framework
US9355273B2 (en) * 2006-12-18 2016-05-31 Bank Of America, N.A., As Collateral Agent System and method for the protection and de-identification of health care data
FR2912841B1 (fr) * 2007-02-15 2009-05-22 Soitec Silicon On Insulator Procede de polissage d'heterostructures
KR101273465B1 (ko) * 2007-03-16 2013-06-14 재단법인서울대학교산학협력재단 집합 검증 장치 및 그 방법
EP2140605A1 (en) * 2007-03-20 2010-01-06 Dmvich Software, Llc Secure electronic messaging system requiring key retrieval for deriving decryption key
JP2008270870A (ja) * 2007-04-16 2008-11-06 Sony Corp 通信システム、通信装置及び通信方法、並びにコンピュータ・プログラム
US10339227B1 (en) 2007-06-08 2019-07-02 Google Llc Data center design
SE532600C2 (sv) * 2007-06-29 2010-03-02 Oniteo Ab Metod och system för säker provisionering av hårdvara
JP5138775B2 (ja) * 2007-07-17 2013-02-06 サーティコム コーポレーション Ｉｄベース暗号化（ｉｂｅ）に対して暗黙の証明証およびアプリケーションを生成する方法およびシステム
US8080900B2 (en) * 2007-07-18 2011-12-20 Exaflop Llc Direct-coupled IT load
US8850195B2 (en) * 2007-07-23 2014-09-30 Intertrust Technologies Corporation Tethered device systems and methods
EP2026266B1 (en) * 2007-07-27 2011-02-16 NTT DoCoMo, Inc. Method and apparatus for performing delegated transactions
JP2009064055A (ja) * 2007-09-04 2009-03-26 Hitachi Ltd 計算機システム及びセキュリティ管理方法
EP2060053B1 (en) 2007-09-14 2017-03-29 Security First Corp. Systems and methods for managing cryptographic keys
US8341410B2 (en) * 2007-10-08 2012-12-25 Microsoft Corporation Efficient certified email protocol
WO2009052217A2 (en) * 2007-10-15 2009-04-23 Penango, Inc. Methods and systems for encouraging secure communications
WO2009052524A2 (en) * 2007-10-20 2009-04-23 Penango, Inc. Methods and systems for indicating trustworthiness of secure communications
JP5139028B2 (ja) * 2007-10-24 2013-02-06 エイチジーエスティーネザーランドビーブイ コンテンツデータ管理システム及び方法
US20090113328A1 (en) * 2007-10-30 2009-04-30 Penango, Inc. Multidimensional Multistate User Interface Element
JP5125426B2 (ja) * 2007-11-06 2013-01-23 沖電気工業株式会社 取引装置及び該取引装置における暗証番号処理方法
CN101197674B (zh) * 2007-12-10 2010-10-27 华为技术有限公司 加密通信方法、服务器及加密通信系统
US20100027790A1 (en) * 2007-12-20 2010-02-04 Balaji Vembu Methods for authenticating a hardware device and providing a secure channel to deliver data
JP2011507414A (ja) 2007-12-21 2011-03-03 コクーン データ ホールディングス リミテッド データの安全を保護するためのシステムおよび方法
EP2077514A1 (en) * 2007-12-28 2009-07-08 British Telecmmunications public limited campany Radio frequency identification devices and processes therefor
EP2238555B1 (en) * 2007-12-28 2015-03-11 BRITISH TELECOMMUNICATIONS public limited company Radio frequency identification devices and reader systems
US9137015B2 (en) * 2008-01-04 2015-09-15 Arcsoft, Inc. Protection scheme for AACS keys
US8473756B2 (en) 2008-01-07 2013-06-25 Security First Corp. Systems and methods for securing data using multi-factor or keyed dispersal
EP2651100A1 (en) 2008-02-22 2013-10-16 Security First Corporation Systems and methods for secure workgroup management and communication
US20090257593A1 (en) * 2008-04-10 2009-10-15 Comverse Ltd. Method and apparatus for secure messaging
JP2009278223A (ja) * 2008-05-13 2009-11-26 Panasonic Corp 電子証明システム及び秘匿通信システム
US8074023B2 (en) * 2008-05-22 2011-12-06 Nuvoton Technology Corporation In-system programming to switch memory access from one area to another in memory cards
US8170216B2 (en) * 2008-06-18 2012-05-01 Apple Inc. Techniques for validating and sharing secrets
US8769612B2 (en) * 2008-08-14 2014-07-01 Microsoft Corporation Portable device association
US8943551B2 (en) 2008-08-14 2015-01-27 Microsoft Corporation Cloud-based device information storage
US8099761B2 (en) * 2008-08-14 2012-01-17 Microsoft Corporation Protocol for device to station association
TWI406175B (zh) * 2008-08-20 2013-08-21 Nuvoton Technology Corp 記憶卡以及用於記憶卡之方法
US20100114607A1 (en) * 2008-11-04 2010-05-06 Sdi Health Llc Method and system for providing reports and segmentation of physician activities
US20100121928A1 (en) 2008-11-07 2010-05-13 Penango, Inc. Methods and systems for allocating and indicating trustworthiness of secure communications
US8370640B2 (en) 2008-12-01 2013-02-05 Research In Motion Limited Simplified multi-factor authentication
US8499154B2 (en) * 2009-01-27 2013-07-30 GM Global Technology Operations LLC System and method for establishing a secure connection with a mobile device
US8374930B2 (en) * 2009-02-02 2013-02-12 Trustifi Corporation Certified email system and method
US9141758B2 (en) * 2009-02-20 2015-09-22 Ims Health Incorporated System and method for encrypting provider identifiers on medical service claim transactions
EP2228942B1 (en) * 2009-03-13 2012-06-06 Sap Ag Securing communications sent by a first user to a second user
BRPI1013062A2 (pt) 2009-05-19 2016-04-05 Security First Corp sistemas e métodos para proteger dados na nuvem
US8178997B2 (en) 2009-06-15 2012-05-15 Google Inc. Supplying grid ancillary services using controllable loads
US8341023B2 (en) * 2009-06-17 2012-12-25 Trustifi Corporation Certified email system and method
US9608826B2 (en) * 2009-06-29 2017-03-28 Jpmorgan Chase Bank, N.A. System and method for partner key management
US8380591B1 (en) * 2009-07-10 2013-02-19 United Services Automobile Association (Usaa) System and method for providing warning and protection for bill payments
US8195819B1 (en) 2009-07-13 2012-06-05 Sprint Communications Company L.P. Application single sign on leveraging virtual local area network identifier
US8887144B1 (en) 2009-09-04 2014-11-11 Amazon Technologies, Inc. Firmware updates during limited time period
US8214653B1 (en) * 2009-09-04 2012-07-03 Amazon Technologies, Inc. Secured firmware updates
US10177934B1 (en) 2009-09-04 2019-01-08 Amazon Technologies, Inc. Firmware updates inaccessible to guests
US9565207B1 (en) 2009-09-04 2017-02-07 Amazon Technologies, Inc. Firmware updates from an external channel
US8102881B1 (en) 2009-09-08 2012-01-24 Amazon Technologies, Inc. Streamlined guest networking in a virtualized environment
US8971538B1 (en) 2009-09-08 2015-03-03 Amazon Technologies, Inc. Firmware validation from an external channel
US8601170B1 (en) 2009-09-08 2013-12-03 Amazon Technologies, Inc. Managing firmware update attempts
US8300641B1 (en) 2009-09-09 2012-10-30 Amazon Technologies, Inc. Leveraging physical network interface functionality for packet processing
US8959611B1 (en) 2009-09-09 2015-02-17 Amazon Technologies, Inc. Secure packet management for bare metal access
US8640220B1 (en) 2009-09-09 2014-01-28 Amazon Technologies, Inc. Co-operative secure packet management
US8381264B1 (en) 2009-09-10 2013-02-19 Amazon Technologies, Inc. Managing hardware reboot and reset in shared environments
WO2011030352A2 (en) * 2009-09-11 2011-03-17 3I Infotech Consumer Services Ltd. System and method for mobile phone resident digital signing and encryption/decryption of sms
AU2010326248B2 (en) 2009-11-25 2015-08-27 Security First Corp. Systems and methods for securing data in motion
EP2507708B1 (en) 2009-12-04 2019-03-27 Cryptography Research, Inc. Verifiable, leak-resistant encryption and decryption
US8917840B2 (en) * 2009-12-14 2014-12-23 International Business Machines Corporation Enhanced privacy caller identification system
US9922063B2 (en) * 2009-12-29 2018-03-20 International Business Machines Corporation Secure storage of secret data in a dispersed storage network
EP2553904A2 (en) 2010-03-31 2013-02-06 Rick L. Orsini Systems and methods for securing data in motion
US8300831B2 (en) * 2010-04-26 2012-10-30 International Business Machines Corporation Redundant key server encryption environment
US8443429B1 (en) 2010-05-24 2013-05-14 Sprint Communications Company L.P. Integrated sign on
WO2011150346A2 (en) 2010-05-28 2011-12-01 Laurich Lawrence A Accelerator system for use with secure data storage
US9443071B2 (en) * 2010-06-18 2016-09-13 At&T Intellectual Property I, L.P. Proximity based device security
EP2651072A3 (en) 2010-09-20 2013-10-23 Security First Corp. Systems and methods for secure data sharing
JP5669517B2 (ja) * 2010-10-18 2015-02-12 オリンパスイメージング株式会社 画像データ販売システムおよび画像データ販売方法ならびに撮影装置、サーバ装置
US8646059B1 (en) 2010-12-17 2014-02-04 Google Inc. Wallet application for interacting with a secure element application without a trusted server for authentication
US8352749B2 (en) 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
US8621168B2 (en) 2010-12-17 2013-12-31 Google Inc. Partitioning the namespace of a contactless smart card
US9619662B1 (en) * 2011-01-13 2017-04-11 Google Inc. Virtual network pairs
US9137014B2 (en) * 2011-01-25 2015-09-15 Adobe Systems Incorporated Systems and methods for controlling electronic document use
US8611544B1 (en) 2011-01-25 2013-12-17 Adobe Systems Incorporated Systems and methods for controlling electronic document use
DE102011001430A1 (de) * 2011-03-21 2012-09-27 Wincor Nixdorf International Gmbh Verfahren zum Betreiben einer Geldkassette mit kundenspezifischen Schlüsseln
US20120272051A1 (en) * 2011-04-22 2012-10-25 International Business Machines Corporation Security key distribution in a cluster
US8775533B2 (en) 2011-05-20 2014-07-08 Microsoft Corporation Auto connect in peer-to-peer network
US8806023B2 (en) 2011-05-20 2014-08-12 Microsoft Corporation Auto-connect in a peer-to-peer network
US9565708B2 (en) 2011-05-20 2017-02-07 Microsoft Technology Licensing, Llc Auto-connect in a peer-to-peer network
US8627508B2 (en) 2011-06-17 2014-01-07 Microsoft Corporation Cloud key directory for federating data exchanges
US10333711B2 (en) * 2011-06-17 2019-06-25 Microsoft Technology Licensing, Llc Controlling access to protected objects
US8891772B2 (en) * 2011-06-17 2014-11-18 Microsoft Corporation Cloud key escrow system
EP2541458B1 (en) * 2011-06-27 2017-10-04 Nxp B.V. Resource management system and corresponding method
US8548172B2 (en) * 2011-07-08 2013-10-01 Sap Ag Secure dissemination of events in a publish/subscribe network
US8914635B2 (en) * 2011-07-25 2014-12-16 Grey Heron Technologies, Llc Method and system for establishing secure communications using composite key cryptography
US8661527B2 (en) 2011-08-31 2014-02-25 Kabushiki Kaisha Toshiba Authenticator, authenticatee and authentication method
US8255687B1 (en) 2011-09-15 2012-08-28 Google Inc. Enabling users to select between secure service providers using a key escrow service
US8171525B1 (en) 2011-09-15 2012-05-01 Google Inc. Enabling users to select between secure service providers using a central trusted service manager
US8313036B1 (en) 2011-09-16 2012-11-20 Google Inc. Secure application directory
US8193662B1 (en) 2011-10-17 2012-06-05 Google Inc. Power supply source blending and smoothing
US9754253B1 (en) 2011-11-28 2017-09-05 Amazon Technologies, Inc. Conditioned use of certificates
CN103188219A (zh) * 2011-12-28 2013-07-03 北大方正集团有限公司 一种数字版权管理方法、设备及系统
US9009500B1 (en) 2012-01-18 2015-04-14 Google Inc. Method of correlating power in a data center by fitting a function to a plurality of pairs of actual power draw values and estimated power draw values determined from monitored CPU utilization of a statistical sample of computers in the data center
US10484355B1 (en) 2017-03-08 2019-11-19 Amazon Technologies, Inc. Detecting digital certificate expiration through request processing
US8385553B1 (en) * 2012-02-28 2013-02-26 Google Inc. Portable secure element
US9065642B2 (en) 2012-03-07 2015-06-23 Certicom Corp. Intercepting key sessions
US8627097B2 (en) 2012-03-27 2014-01-07 Igt System and method enabling parallel processing of hash functions using authentication checkpoint hashes
US8843739B2 (en) * 2012-04-04 2014-09-23 Lockheed Martin Corporation Anti-tamper device, system, method, and computer-readable medium
US8429409B1 (en) 2012-04-06 2013-04-23 Google Inc. Secure reset of personal and service provider information on mobile devices
CN102664893B (zh) * 2012-04-23 2015-06-24 重庆理工大学 自适应重传与分段嵌入签名的数据传输方法
US8832443B2 (en) * 2012-05-31 2014-09-09 Daon Holdings Limited Methods and systems for increasing the security of private keys
US9032250B1 (en) 2012-11-05 2015-05-12 Google Inc. Online testing of secondary power unit
KR101442504B1 (ko) 2012-12-28 2014-09-23 사단법인 금융보안연구원 거래인증을 이용한 경량화된 부인방지시스템
US9485096B2 (en) * 2013-02-06 2016-11-01 Apurva Shrivastava Encryption / decryption of data with non-persistent, non-shared passkey
WO2014127147A1 (en) 2013-02-13 2014-08-21 Security First Corp. Systems and methods for a cryptographic file system layer
US20140237258A1 (en) * 2013-02-20 2014-08-21 Kabushiki Kaisha Toshiba Device and authentication method therefor
US9780950B1 (en) * 2013-03-15 2017-10-03 Symantec Corporation Authentication of PKI credential by use of a one time password and pin
US9059987B1 (en) 2013-04-04 2015-06-16 Sprint Communications Company L.P. Methods and systems of using single sign-on for identification for a web server not integrated with an enterprise network
ES2523423B1 (es) 2013-04-10 2015-11-24 Crypto Solutions, S.L. Dispositivo de cifrado simetrico y procedimiento empleado
US9032106B2 (en) 2013-05-29 2015-05-12 Microsoft Technology Licensing, Llc Synchronizing device association data among computing devices
US10181124B2 (en) * 2013-05-30 2019-01-15 Dell Products, L.P. Verifying OEM components within an information handling system using original equipment manufacturer (OEM) identifier
JP6151140B2 (ja) * 2013-09-13 2017-06-21 株式会社日立製作所 情報の暗号化・復号化方法、情報提供システムおよびプログラム
WO2015048389A1 (en) * 2013-09-26 2015-04-02 Krimmeni Technologies, Inc. Systems and methods for establishing and using distributed key servers
US9874414B1 (en) 2013-12-06 2018-01-23 Google Llc Thermal control system
GB2522032A (en) 2014-01-10 2015-07-15 Ibm Controlling the configuration of computer systems
US8978153B1 (en) 2014-08-01 2015-03-10 Datalogix, Inc. Apparatus and method for data matching and anonymization
CN105578461B (zh) * 2014-11-10 2019-08-02 阿里巴巴集团控股有限公司 在移动终端间建立通讯、通讯接入/呼出方法、装置及系统
US10031679B2 (en) 2014-11-21 2018-07-24 Security First Corp. Gateway for cloud-based secure storage
US10453058B2 (en) 2014-12-17 2019-10-22 Heartland Payment Systems, Inc. E-signature
US9805344B1 (en) 2015-01-23 2017-10-31 Island Intellectual Property, Llc Notification system and method
US10057067B2 (en) * 2015-05-27 2018-08-21 International Business Machines Corporation Automatic root key rollover during digital signature verification
CN106549919B (zh) * 2015-09-21 2021-01-22 创新先进技术有限公司 一种信息注册、认证方法及装置
US10567357B2 (en) * 2015-10-02 2020-02-18 Zixcorp Systems, Inc. Secure transmission system with upgraded encryption strength
JP6966439B2 (ja) 2015-11-20 2021-11-17 ジェネテック インコーポレイテッド メディア・ストリーミング
EP3430563B1 (en) * 2016-03-15 2020-09-09 Visa International Service Association Validation cryptogram for interaction
US10129025B2 (en) * 2016-09-19 2018-11-13 Red Hat, Inc. Binding data to a network in the presence of an entity with revocation capabilities
CN110383281A (zh) * 2017-01-04 2019-10-25 格哈德·施瓦茨 非对称系统与网络体系结构
US10516542B2 (en) * 2017-03-08 2019-12-24 Amazon Technologies, Inc. Digital certificate issuance and monitoring
US10615987B2 (en) 2017-03-08 2020-04-07 Amazon Technologies, Inc. Digital certificate usage monitoring systems
US10990707B1 (en) 2017-03-30 2021-04-27 Comodo Security Solutions, Inc. Device for safe data signing
US10440006B2 (en) 2017-06-21 2019-10-08 Microsoft Technology Licensing, Llc Device with embedded certificate authority
US10558812B2 (en) 2017-06-21 2020-02-11 Microsoft Technology Licensing, Llc Mutual authentication with integrity attestation
US10938560B2 (en) 2017-06-21 2021-03-02 Microsoft Technology Licensing, Llc Authorization key escrow
US10715504B2 (en) * 2017-07-12 2020-07-14 Wickr Inc. Provisioning ephemeral key pools for sending and receiving secure communications
US11316666B2 (en) 2017-07-12 2022-04-26 Amazon Technologies, Inc. Generating ephemeral key pools for sending and receiving secure communications
US11082412B2 (en) 2017-07-12 2021-08-03 Wickr Inc. Sending secure communications using a local ephemeral key pool
CN113765657B (zh) 2017-08-28 2023-10-24 创新先进技术有限公司 一种密钥数据处理方法、装置及服务器
US11368442B2 (en) * 2017-08-29 2022-06-21 Amazon Technologies, Inc. Receiving an encrypted communication from a user in a second secure communication network
US11349659B2 (en) * 2017-08-29 2022-05-31 Amazon Technologies, Inc. Transmitting an encrypted communication to a user in a second secure communication network
US10791196B2 (en) 2017-08-29 2020-09-29 Wickr Inc. Directory lookup for federated messaging with a user from a different secure communication network
US11095662B2 (en) 2017-08-29 2021-08-17 Amazon Technologies, Inc. Federated messaging
US10546276B2 (en) * 2017-09-13 2020-01-28 Microsoft Technology Licensing, Llc Cyber ownership transfer
US11374760B2 (en) 2017-09-13 2022-06-28 Microsoft Technology Licensing, Llc Cyber physical key
US10693662B2 (en) * 2018-02-22 2020-06-23 Idlogiq Inc. Methods for secure serialization of supply chain product units
US20190288833A1 (en) * 2018-03-16 2019-09-19 Walmart Apollo, Llc System and Method for Securing Private Keys Behind a Biometric Authentication Gateway
US11854007B2 (en) * 2018-04-16 2023-12-26 Visa International Service Association Method and system for pre-authorizing a delivery transaction
US10867046B2 (en) * 2018-08-08 2020-12-15 Quanta Computer Inc. Methods and apparatus for authenticating a firmware settings input file
CN109598489A (zh) * 2018-11-09 2019-04-09 海南新软软件有限公司 一种数字钱包助记词存储的方法、装置及系统
CN109547212B (zh) * 2018-12-04 2021-06-18 中国电子科技集团公司第三十研究所 一种基于sm2签名算法的门限签名方法
US11979508B2 (en) 2018-12-14 2024-05-07 Iot And M2M Technologies, Llc Secure IDS certificate verification for a primary platform
FI3671663T3 (fi) * 2018-12-20 2024-09-11 Assa Abloy Ab Yhteisallekirjoitusvaltuutukset
US11477086B2 (en) * 2019-05-08 2022-10-18 Schlumberger Technology Corporation Methods and systems for provisioning and commissioning an industrial gateway
US11233658B2 (en) 2019-08-14 2022-01-25 OX Labs Inc. Digital transaction signing for multiple client devices using secured encrypted private keys
CN110765438B (zh) * 2019-10-24 2021-01-01 江苏云涌电子科技股份有限公司 一种高性能密码卡及其工作方法
US11671265B2 (en) 2019-10-25 2023-06-06 John A. Nix Secure configuration of a secondary platform bundle within a primary platform
US12050692B2 (en) 2019-10-30 2024-07-30 John A. Nix Secure and flexible boot firmware update for devices with a primary platform
US11216433B2 (en) 2019-12-12 2022-01-04 Google Llc Encrypted search with no zero-day leakage
US11438152B2 (en) * 2020-01-31 2022-09-06 Visa International Service Association Distributed symmetric encryption
FR3107414A1 (fr) * 2020-02-19 2021-08-20 Orange Procédé de calcul d’une clé de session, procédé de récupération d’une telle clé de session
JP7502618B2 (ja) * 2020-07-20 2024-06-19 富士通株式会社 通信プログラム、通信装置、及び通信方法
EP3951516A1 (de) * 2020-08-04 2022-02-09 Siemens Aktiengesellschaft System und verfahren zum verifizieren von komponenten eines industriellen kontrollsystems
US11502830B2 (en) 2020-10-12 2022-11-15 Kyndryl, Inc. Ultrasound split key transmission for enhanced security
CN112463454B (zh) * 2020-12-04 2021-11-05 北京深思数盾科技股份有限公司 数据恢复方法、服务器、终端设备及存储介质
US11372986B1 (en) * 2021-01-18 2022-06-28 Axiom Technologies LLC Systems and methods for encrypted content management
IT202100017405A1 (it) 2021-07-01 2023-01-01 Telecom Italia Spa “metodo e sistema per la decifratura di messaggi cifrati end-to-end per intercettazione legale”
IL291459A (en) * 2022-03-17 2023-10-01 Kazuar Advanced Tech Ltd Key management system
CN114785527B (zh) * 2022-06-17 2022-09-16 深圳市深圳通有限公司 数据传输方法、装置、设备及存储介质

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4200770A (en) * 1977-09-06 1980-04-29 Stanford University Cryptographic apparatus and method
US4218582A (en) * 1977-10-06 1980-08-19 The Board Of Trustees Of The Leland Stanford Junior University Public key cryptographic apparatus and method
US4405829A (en) * 1977-12-14 1983-09-20 Massachusetts Institute Of Technology Cryptographic communications system and method
US4558176A (en) * 1982-09-20 1985-12-10 Arnold Mark G Computer systems to inhibit unauthorized copying, unauthorized usage, and automated cracking of protected software
US4748620A (en) * 1986-02-28 1988-05-31 American Telephone And Telegraph Company, At&T Bell Laboratories Time stamp and packet virtual sequence numbering for reconstructing information signals from packets
US4771461A (en) * 1986-06-27 1988-09-13 International Business Machines Corporation Initialization of cryptographic variables in an EFT/POS network with a large number of terminals
JPS63317862A (ja) * 1987-06-12 1988-12-26 エイ・ティ・アンド・ティ　グローバル　インフォメーション　ソルーションズ　インターナショナル　インコーポレイテッド 安全モジユールの動作制御方法
US5214702A (en) * 1988-02-12 1993-05-25 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5005200A (en) * 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US4868877A (en) * 1988-02-12 1989-09-19 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US4888801A (en) * 1988-05-02 1989-12-19 Motorola, Inc. Hierarchical key management system
EP0383985A1 (de) * 1989-02-24 1990-08-29 Claus Peter Prof. Dr. Schnorr Verfahren zur Identifikation von Teilnehmern sowie zur Generierung und Verifikation von elektronischen Unterschriften in einem Datenaustauschsystem
US5175765A (en) * 1989-05-09 1992-12-29 Digital Equipment Corporation Robust data broadcast over a distributed network with malicious failures
DE3922642A1 (de) * 1989-07-10 1991-01-24 Ant Nachrichtentech Verfahren zur verschluesselten datenuebertragung
US5001752A (en) * 1989-10-13 1991-03-19 Fischer Addison M Public/key date-time notary facility
US5136643A (en) * 1989-10-13 1992-08-04 Fischer Addison M Public/key date-time notary facility
JP2874916B2 (ja) * 1989-11-21 1999-03-24 株式会社東芝 携帯用暗号鍵記憶装置
FR2662007B1 (fr) * 1990-05-10 1992-07-10 Bull Sa Procede d'obtention d'une attestation en clair securisee dans un environnement de systeme informatique distribue.
US5070528A (en) * 1990-06-29 1991-12-03 Digital Equipment Corporation Generic encryption technique for communication networks
ATE119726T1 (de) * 1990-10-24 1995-03-15 Omnisec Ag Geheimübertragungssystem mit möglichkeit zur verschlüsselten kommunikation zwischen benutzern mit gesichertem schlüssel, welcher ohne benutzereinwirkung bestimmt wird.
US5073934A (en) * 1990-10-24 1991-12-17 International Business Machines Corporation Method and apparatus for controlling the use of a public key, based on the level of import integrity for the key
US5199070A (en) * 1990-12-18 1993-03-30 Matsushita Electric Industrial Co., Ltd. Method for generating a public key
JP3027988B2 (ja) * 1991-01-31 2000-04-04 松下電器産業株式会社 識別情報に基づく秘密鍵生成方法
US5200999A (en) * 1991-09-27 1993-04-06 International Business Machines Corporation Public key cryptosystem key management based on control vectors
US5164988A (en) * 1991-10-31 1992-11-17 International Business Machines Corporation Method to establish and enforce a network cryptographic security policy in a public key cryptosystem
US5222140A (en) * 1991-11-08 1993-06-22 Bell Communications Research, Inc. Cryptographic method for key agreement and user authentication
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5261002A (en) * 1992-03-13 1993-11-09 Digital Equipment Corporation Method of issuance and revocation of certificates of authenticity used in public key networks and other systems
US5313521A (en) * 1992-04-15 1994-05-17 Fujitsu Limited Key distribution protocol for file transfer in the local area network
US5315658B1 (en) * 1992-04-20 1995-09-12 Silvio Micali Fair cryptosystems and methods of use
US5276737B1 (en) * 1992-04-20 1995-09-12 Silvio Micali Fair cryptosystems and methods of use
DE69323926T2 (de) * 1992-05-15 1999-09-30 Addison M. Fischer Verfahren und Vorrichtung zur Sicherheit eines Computersystem mit Programmberechtigungsdatenstrukturen
US5396558A (en) * 1992-09-18 1995-03-07 Nippon Telegraph And Telephone Corporation Method and apparatus for settlement of accounts by IC cards
US5349642A (en) * 1992-11-03 1994-09-20 Novell, Inc. Method and apparatus for authentication of client server communication
US5499295A (en) * 1993-08-31 1996-03-12 Ericsson Inc. Method and apparatus for feature authorization and software copy protection in RF communications devices
US5371794A (en) * 1993-11-02 1994-12-06 Sun Microsystems, Inc. Method and apparatus for privacy and authentication in wireless networks
US5787172A (en) * 1994-02-24 1998-07-28 The Merdan Group, Inc. Apparatus and method for establishing a cryptographic link between elements of a system
US5539828A (en) * 1994-05-31 1996-07-23 Intel Corporation Apparatus and method for providing secured communications
US5557346A (en) * 1994-08-11 1996-09-17 Trusted Information Systems, Inc. System and method for key escrow encryption

Also Published As

Publication number Publication date
ES2158081T3 (es) 2001-09-01
OA10456A (en) 2002-03-27
JP2007282295A (ja) 2007-10-25
PL176458B1 (pl) 1999-05-31
AU1680395A (en) 1995-08-01
US5872849A (en) 1999-02-16
US5850451A (en) 1998-12-15
US6009177A (en) 1999-12-28
US5857022A (en) 1999-01-05
US5841865A (en) 1998-11-24
US5799086A (en) 1998-08-25
UA41387C2 (uk) 2001-09-17
DE69521413T2 (de) 2002-05-29
WO1995019672A3 (en) 1995-09-08
DK0739560T3 (da) 2001-10-01
HUT75800A (en) 1997-05-28
HU9601870D0 (en) 1996-08-28
GR3036650T3 (en) 2001-12-31
CA2176032A1 (en) 1995-07-20
DE69521413D1 (de) 2001-07-26
MX9602773A (es) 1997-05-31
BR9506414A (pt) 1997-09-09
ATE202439T1 (de) 2001-07-15
AP626A (en) 1998-01-16
WO1995019672A2 (en) 1995-07-20
CN1138927A (zh) 1996-12-25
PL315574A1 (en) 1996-11-12
NZ279622A (en) 1998-04-27
CZ197896A3 (en) 1997-03-12
HU216231B (hu) 1999-05-28
JPH09507729A (ja) 1997-08-05
JP2006246543A (ja) 2006-09-14
JP2005328574A (ja) 2005-11-24
NZ329891A (en) 2000-01-28
AP9600811A0 (en) 1996-07-31
EP0739560A1 (en) 1996-10-30
EP0739560B1 (en) 2001-06-20

Similar Documents

Publication Publication Date Title
PT739560E (pt) Sistema criptografico e processo com caracteristica de garantia de chave
US20010050990A1 (en) Method for initiating a stream-oriented encrypted communication
CA2232170C (en) Document authentication system and method
US6237096B1 (en) System and method for electronic transmission storage and retrieval of authenticated documents
JP5680115B2 (ja) データ・セキュリティ装置のためのトランザクション監査
US5615268A (en) System and method for electronic transmission storage and retrieval of authenticated documents
USRE38070E1 (en) Cryptography system and method for providing cryptographic services for a computer application
US20100268942A1 (en) Systems and Methods for Using Cryptographic Keys
EP1253744A2 (en) Method for generation and management of a secret key in a public key cryptosystem
Zhang et al. Achieving non-repudiation of receipt
JP2005537559A (ja) トランザクションの安全な記録
Lee Guideline for implementing cryptography in the federal government
AU705473B2 (en) Cryptographic system and method with key escrow feature
AU4461999A (en) Cryptographic system and method with key escrow feature
AU758834B2 (en) Document authentication system and method