BR102012010346A2 - Servidor de assinatura de extensão de segurança de sistema de nome de domínio (dnssec) e método de criptografar informações de sistema de nome de domínio (dns) utilizando o mesmo - Google Patents

Servidor de assinatura de extensão de segurança de sistema de nome de domínio (dnssec) e método de criptografar informações de sistema de nome de domínio (dns) utilizando o mesmo Download PDF

Info

Publication number
BR102012010346A2
BR102012010346A2 BRBR102012010346-0A BR102012010346A BR102012010346A2 BR 102012010346 A2 BR102012010346 A2 BR 102012010346A2 BR 102012010346 A BR102012010346 A BR 102012010346A BR 102012010346 A2 BR102012010346 A2 BR 102012010346A2
Authority
BR
Brazil
Prior art keywords
data
server
active
subscription
digital signature
Prior art date
Application number
BRBR102012010346-0A
Other languages
English (en)
Inventor
David Smith
James Gould
Ramana Lavu
Deepak Deshpande
Original Assignee
Verisign 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 Verisign Inc filed Critical Verisign Inc
Publication of BR102012010346A2 publication Critical patent/BR102012010346A2/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/321—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 a third party or a trusted authority
    • 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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Servidor de assinatura de extensão de segurança de sistema de nome de domínio (dnssec) e método de criptografar informações de sistema de nome de domínio (dns) utilizando o mesmo. Sistemas e métodos para realizar assinatura dnssec são descritos em que operações de assinatura digital podem ser realizadas por um servidor de assinatura acessível por rede que é configurado para interagir com uma aplicação de cliente separada. Métodos exemplares podem incluir receber uma solicitação de assinatura no servidor de assinatura a partir da aplicação cliente para assinar os primeiros dados. O servidor de assinatura pode determinar uma ksk ativa e / ou zsk ativa para os primeiros dados. Os primeiros dados podem então ser transmitidos por um servidor de assinatura para módulos de assinatura digital, que pode incluir, por exemplo, um módulo de suporte de hardware, ou aplicações de assinatura de software. O servidor de assinatura pode receber uma versão assinada digitalmente dos primeiros dados a partir do módulo de assinatura digital, e fornecer os primeiros dados assinados para a aplicação cliente.

Description

SERVIDOR DE ASSINATURA DNSSEC O Sistema de Nome de Domínio (DNS) é a parte da infraestrutura de Internet que traduz nomes de domínio legíveis por humanos em números de Protocolo de Internet (IP) necessários para estabelecer comunicações TCP / IP sobre a Internet. Isto é, DNS permite usuários referirem a páginas web, e outros recursos, usando nomes de domínio mais fáceis de lembrar, tais como "www.en.example.com", em vez de endereço IP numérico, tal como "123.4.56.78", que são endereços legíveis por máquina usados por software para comunicar com computadores na internet. Cada nome de domínio é feito de uma série de strings de caracteres (marcadores) separados por pontos. O marcador mais a direita em um nome de domínio é conhecido como "domínio de alto nível" (TLD) . Exemplos de bem conhecidos TLDs são ".com", ".net" e ",org" etc. Cada TLD suporta domínios de segundo nivel, listados imediatamente a esquerda do TLD, por exemplo, "example" em "www.example.com". Cada domínio de segundo nível pode suportar um número de domínios de terceiro nível localizados imediatamente a direita dos domínios de segundo nível, por exemplo, "en" em "www.en.example.com". Pode ser adicionado domínios de nível adicionais também. Por exemplo, um domínio com niveis de domínio adicionais pode ser "www.landscaoe.photos.example.com".
Deve notar-se que um único endereço IP, por exemplo, um atribuído a um único servidor, pode suportar numerosos nomes de domínio. Ou seja, diferentes nomes de domínio podem determinar para o mesmo servidor, que pode, então, determinar que conteúdo fornecer com base no nome de domínio solicitado e / ou informações de não domínio adicionais. Isto é muitas vezes referido como hospedagem virtual.
Informações de não domínio adicionais podem ser incluídas em uma estrutura de Identificador de Recurso Uniforme ("URI") que inclui o nome de domínio. Por exemplo, uma parte de "caminho" é uma seqüência de segmentos separados por uma barra ("/") . Esta informação pode ser incluída imediatamente à direita do nome do domínio, tal como "blog" em www.example.com /blog/today.htm, e pode ser usada por um servidor, ou outro dispositivo receptor para identificar e apresentar um conteúdo específico ou executar um código particular. Outros exemplos de informações de não domínio podem incluir consultas e fragmentos, as especificidades de tais são compreendidas por aqueles com conhecimentos normais na arte e não são discutidas em detalhes. Combinações desta informação podem ser incluídas em hiperlinks de página web que navegam um usuário para outra seção da mesma página ou para outra página web.
Assim, como pode ser visto em vários exemplos fornecidos acima, e como apreciado por aqueles que são peritos na arte, um domínio, tal como o domínio de segundo nível "example.com", pode conter uma variedade de informação acessível de Internet diferente com diferentes endereços e outros meios de identificação. O registro real de nomes de domínio é realizado por empresas referidas com registradores de nomes de domínio ("registradores") . Registradores registram nomes de domínio com os registros. Por exemplo, um usuário submete a um registrador um nome de domínio para registro e fornece um endereço IP ao qual o nome de domínio deve determinar. O registrador comunica com o registro para criar uma gravação de banco de dados de registro que pode ser usada para determinar o nome de domínio para o endereço IP fornecido ao usuário final e indica a identidade do registrador através do qual o nome de domínio foi registrado. Exceto para o término do registro de nome de domínio no registro, normalmente só o registrado designado no registro de nome de domínio no registro pode modificar ou apagar informações de banco de dados de registro sobre um nome de domínio. Um usuário final pode mudar registradores, seguindo certos procedimentos de transferência de dominio. Os registradores também podem atuar como um serviço de hospedagem, ou o usuário final pode ter o domínio hospedado por um serviço de hospedagem de domínio terceirizado separado.
Um arquivo de zona é um arquivo de texto que descreve uma porção do DNS chamada de zona DNS. Um arquivo de zona é organizado sob a forma de gravações de recursos (RR) e contém informações que definem mapeamentos entre nomes de domínio e endereços IP e outros recursos. O formato dos arquivos de zona é definido por um padrão, com cada linha tipicamente definindo um único registro de recurso. A linha começa com um nome de dominio, mas se deixada em branco, o padrão é o nome de dominio previamente definido. Seguindo o nome de domínio é o tempo de viver (TTL) , a classe (que é quase sempre "IN" para "internet" e raramente incluída), o tipo de registro de recurso (A, MX, SOA, etc) , seguido por dados de tipo especifico, como o endereço IPv4 para A registros. Os comentários podem ser incluídos por meio de um ponto e vírgula e linhas podem ser continuadas usando parênteses. Há também diretivas de arquivo que são marcadas com uma palavra-chave começando com um sinal de dólar. O DNS distribui a responsabilidade de atribuir nomes de domínio e mapear esses nomes para endereços IP através da designação de servidores de nome autorizados para cada domínio. Servidores de nome autorizados são atribuídos para serem responsáveis pelos seus domínios particulares, e por sua vez podem atribuir outros servidores de nome autorizados para seus subdominios. Este mecanismo geralmente ajuda a evitar a necessidade de um único registro central a ser continuamente consultado e atualizado. O processo de resolução de DNS permite que usuários sejam dirigidos a um domínio desejado por um processo de pesquisa inversa através do qual o usuário entra no domínio desejado, e o DNS retorna números IP apropriados. Durante o processo de resolução de DNS, um pedido para um determinado nome de domínio é encaminhado a partir de um resolvedor (por exemplo, resolverdor de ponta) para um servidor apropriado (por exemplo, um resolvedor recursivo) para recuperar o endereço IP. Para melhorar a eficiência, reduzir o tráfego de DNS através da Internet e aumentar o desempenho em aplicativos de usuário final, o DNS suporta servidores cachê DNS que armazenam os resultados de consulta de DNS por um período de tempo determinado pelo tempo para viver (TTL) do registro de nome de domínio em questão. Geralmente, os servidores cachê DNS deste tipo, também chamados de cachês DNS, também implementam o algoritmo recursivo necessário para determinar um nome dado a partir da raiz de DNS até os servidores de nome autorizados do domínio consultado.
Provedores de Serviço de Internet (ISPs) normalmente fornecem servidores DNS de cachê e recursivos para seus clientes. Além disso, os roteadores de rede doméstica podem implementar cachês DNS e proxies para melhorar a eficiência na rede local.
Embora a natureza distribuída do DNS forneça vantagens significativas em termos de eficiência de todo o sistema também torna o sistema vulnerável a certos tipos de avarias e / ou ataques em vários nós no sistema. Um problema particular que pode ocorrer é referido como envenenamento de cachê DNS. Envenenamento de cachê DNS ocorre quando os dados são introduzidos no banco de dados de cachê de um servidor de nome DNS que não se originou a partir de fontes de DNS autorizadas. Isto pode resultar de ataques deliberados contra um servidor de nome, ou pode ser um resultado não intencional de, por exemplo, um cachê DNS configurado incorretamente ou projeto de software indevido de algumas aplicações de DNS. Assim envenenamento de cachê pode resultar em (1) solicitações de resolução falhando, como quando informações de endereço IP imprecisas ou mal configuradas são fornecidas, ou (2) uma solicitação de resolução do usuário solicitador que está sendo direcionada para um site malicioso que satiriza o domínio genuíno e é usado para ilicitamente obter informações como senhas de contas, ou para distribuir conteúdo malicioso, como worms ou vírus de computador, que são entregues ao usuário solicitador. A Extensão de Segurança de Sistema de Nome de Domínio (DNSSEC) é um pacote de especificações de Força Tarefa de Engenharia de Internet (IETF) para garantir certos tipos de informações fornecidas pelo DNS, como usadas em redes IP. DNSSEC fornece par a assinatura de arquivos de zona DNS preparado, garantindo a autenticação de origem e integridade de dados para dados DNS, bem como a negação autenticada de existência. Em geral, as respostas fornecidas dentro de DNSSEC são assinadas digitalmente, e, através da verificação da assinatura digital, um resolvedor DNS é capaz de verificar se a informação corresponde às informações sobre o servidor de DNS autorizado. DNSSEC utiliza criptografia de chave pública para as assinaturas digitais e autenticação. O registro DNSKEY é autenticado via uma cadeia de confiança, começando com um conjunto de chaves públicas verificadas para a zona de raiz DNS, que é uma terceira parte confiável.
Para implementar DNSSEC, vários novos tipos de gravações DNS foram criados ou adaptados para uso com DNSSEC, incluindo RRSIG, DNSKEY, DS, NSEC, e NSEC3PARAM. Por exemplo, quando DNSSEC é usada, cada resposta autorizada a uma pesquisa de DNS irá conter um registro RRSIG DNS além do tipo de registro que foi solicitado, o registro RRSIG é uma assinatura digital do conjunto de gravações de recursos DNS de resposta. A assinatura digital pode ser verificada por localização da chave pública correta encontrada no registro DNSKEY. O registro DS é usado na autenticação de DNSKEYs no processo de pesquisa usando a cadeia de confiança. Gravações NSEC e NSEC3 são usadas para fornecer a negação autenticada de respostas de existência para gravações DNS que não existem.
Os requisitos de DNSSEC envolvem a utilização de chaves diferentes, armazenadas tanto em gravações DNSKEY e de outras fontes para formar âncoras de confiança. Há, por exemplo, Chaves de Assinatura de Chave (KSKs), que são utilizadas para assinar outras gravações DNSKEY e Chaves de Assinatura de Zona (ZSKs), que são utilizadas para assinar outras gravações. Porque as ZSKs estão sob o controle e a utilização de uma zona DNS especifica, elas podem ser comutadas mais facilmente e mais frequentemente. Como resultado, ZSKs geralmente podem ser muito mais curtas (em termos de comprimento de bytes) do que KSKs, enquanto ainda oferece um nivel aceitável de proteção.
Embora os protocolos tenham sido desenvolvidos para o emprego de DNSSEC, incluindo o uso de KSKs e ZSKs, existem vários aspectos da operação de domínios DNSSEC habilitados, nos níveis de registros e regi stradores, que não foram tratados e / ou otimizados para uso em larga escala. Por exemplo, a capacidade de processar grandes números de assinaturas em curtos períodos de tempo, está limitada às práticas comuns da utilização de sistemas independentes de assinatura e assinatura de zonas inteiras baseada em alterações na zona. Além disso, as soluções podem se limitar aos usuários individuais, ou um número limitado de domínios, etc que pode ser gerenciado por um provedor DNS particular. Assim, há necessidades em andamento para melhorar ainda mais a funcionalidade e / ou eficiência das operações relacionadas com gestão DNSSEC e as funções de assinatura necessárias para gravações DNSSEC.
SUMÁRIO DA INVENÇÃO A maioria das técnicas DNSSEC atuais envolvem a assinatura de dados DNSSEC dentro de aplicações de gestão de zona e servindo zona limitadas, por exemplo, limitadas pelo usuário, provedores DNS, etc. Atualmente, os usuários que desejem adotar DNSSEC tem as seguintes opções básicas: 1 . Construir sua própria solução DNSSEC usando uma combinação de software de código aberto e de terceiros, juntamente com um conjunto de chaves de software ou chaves de hardware. 2 . Usar uma gestão de chave DNSSEC e um aparelho de assinatura como "Secure64 DNS Signer", "BlueCat Networks", "Xelerance DNSX Secure", "Signer" e "Infoblox". Estes aparelhos podem fornecer vários aspectos de gestão de chaves e assinatura de zona, mas exigem hardware para serem instalados no local do cliente. Note-se que a gestão de chaves DNSSEC e aparelhos de assinatura requerem a instalação de hardware no local do usuário, requerem mais gestão real de material de chave, e não suportam mais do que um único usuário. 3. Usar uma solução DNS Gerenciada que foi atualizada para suportar DNSSEC. Provedores DNS Gerenciados incluem a gestão de zonas e recursos de publicação de zona. Capacitação DNSSEC permite que um cliente "ligue" DNSSEC para uma zona DNS gerenciada, mas exige que o usuário migre ou terceirize sua hospedagem DNS para o provedor DNS gerenciado.
No entanto, com a introdução de DNSSEC em registros vastos, como os registros.com e .net, ineficiências das várias técnicas de assinatura para dados DNSSEC, particularmente no que diz respeito a zonas grandes, trouxeram o potencial para resolução de problemas incluindo atrasos e resolução de falhas. Tais problemas podem ter importantes efeitos prejudiciais sobre e-commerce e outros sites de alto tráfego. O assunto presente pode proporcionar benefícios na assinatura eficiente de zona habilitadas DNSSEC através da utilização de um servidor de assinatura acessível por rede que permite que uma aplicação remota gerencie a assinatura, e também remotamente assine porções de dados de zona, conforme necessário. De acordo com aspectos da invenção, a utilização de um servidor de assinatura acessível por rede pode fornecer a dissociação da aplicação de gestão de zona e servindo zona do mecanismo de assinatura, em comparação com outras técnicas em que as funções são essencialmente fundidas, por exemplo, em técnicas onde os servidores de nomes executam a assinatura ou nos casos em que um dispositivo de gestão de zona específico faz a assinatura.
Através do uso de, por exemplo, um servidor de assinatura extensível, acessível por rede, configurações exemplares podem também reduzir, ou eliminar, a necessidade de configurar manualmente várias funções do servidor de assinatura em comparação com outras técnicas conhecidas. Um servidor de assinatura acessível por rede pode também fornecer suporte para uma vasta gama de aplicações DNSSEC sem a necessidade de configuração manual, tais como: 1. Assinatura em linha de gravações de recursos em uma aplicação DNSSEC de alto volume, por exemplo, um registro TLD. 2. Dinamicamente criar chaves, carregar chaves, descarregar chaves, e usar as chaves para assinar os dados de zona em uma aplicação DNSSEC com muitas chaves e zonas. 3. Assinar uma zona inteira em uma aplicação DNSSEC offline / lote, por exemplo, uma zona RAIZ.
Em modalidades, sistemas e métodos para a realização de assinatura DNSSEC podem ser realizados por um servidor de assinatura que está configurado para interagir com uma aplicação cliente separada. Exemplos de métodos podem geralmente incluir o recebimento de uma solicitação de assinatura no servidor da aplicação cliente para assinar primeiros dados. O servidor de assinatura poderá determinar as chaves de assinatura apropriadas e / ou protocolos para os primeiros dados. Os primeiros dados podem ser transmitidos pelo servidor de assinatura para um módulo de assinatura digital, que pode incluir, por exemplo, um módulo de suporte de hardware, ou aplicações de assinatura de software. O servidor de assinatura pode receber uma versão assinada digitalmente dos primeiros dados do módulo de assinatura digital, e fornecer os primeiros dados assinados para a aplicação cliente.
De acordo com primeiros aspectos da invenção, uma assinatura DNSSEC pode ser configurada para interagir com pelo menos uma aplicação cliente DNSSEC e um módulo de assinatura digital. 0 servidor de assinatura DNSSEC pode incluir, por exemplo, um processador e um dispositivo de armazenamento, incluindo o código legível por computador que, quando executado pelo processador, faz com que o servidor de assinatura atue como um servidor de assinatura autorizado configurado para receber uma solicitação de assinatura do pelo menos uma aplicação cliente para assinar os primeiros dados. Os primeiros dados podem incluir, por exemplo, os dados DNS.
Em modalidades, o servidor de assinatura pode determinar uma chave de assinatura apropriada, por exemplo, pelo menos uma de uma KSK ativa e uma ZSK ativa, para os primeiros dados. Chaves adequadas, tais como a pelo menos uma KSK ativa e ZSK ativa, podem ser determinadas com base em, por exemplo, um identificador TLD incluído na solicitação de assinatura. Em modalidades, o servidor de assinatura pode ser configurado para determinar mais do que uma chave de assinatura ativa e / ou algoritmo de assinatura ativo para os primeiros dados, e pode requerer uma pluralidade de assinaturas diferentes para os primeiros dados com base em mais que uma chave de assinatura ativa e / ou algoritmo de assinatura ativo.
Em modalidades, o servidor de assinatura pode transmitir os primeiros dados a um de uma pluralidade de módulos de assinatura digital, e pode receber uma versão assinada digitalmente dos primeiros dados a partir do módulo de assinatura digital. O servidor de assinatura também pode ser configurado para fornecer os primeiros dados assinados para a aplicação cliente.
Em modalidades, o servidor de assinatura pode ser configurado para distinguir uma função de assinatura requerida de entre a pluralidade de diferentes funções de assinatura digital com base em um identificador de tipo de serviço incluído na solicitação, e para rotear solicitação de assinatura não DNSSEC para um módulo digital não DNSSEC com base no identificador de tipo de serviço.
De acordo com aspectos adicionais da invenção, o servidor de assinatura pode também ser configurado para receber, como parte da mesma solicitação de assinatura, uma solicitação para assinar segundos dados. Os segundos dados podem ser, por exemplo, DNS, ou outros dados. O servidor de assinatura pode determinar uma chave de assinatura apropriada, por exemplo, pelo menos uma de uma KSK ativa e uma ZSK ativa, para os segundos dados, que pode ser diferente do que a chave para ser usada com os primeiros dados. Por exemplo, o servidor de assinatura pode determinar um primeiro conjunto de chaves para os primeiros dados e um segundo conjunto de chaves para os dados segundo.
Em modalidades, o servidor de assinatura pode transmitir os segundos dados a um de uma pluralidade de módulos de assinatura digital, e receber uma versão assinada digitalmente dos segundos dados a partir do módulo de assinatura digital. O servidor de assinatura também pode ser configurado para fornecer os segundos dados assinados para a aplicação cliente.
Modalidades podem incluir, em que o servidor de assinatura é configurado para receber várias solicitações de assinatura como parte de um único pacote de solicitação e analisar o pacote de solicitação para identificar as solicitações de assinatura diferentes que têm pelo menos uma de KSKs ativas, ZSKs ativas, e protocolos de assinatura diferentes um do outro.
Em modalidades, os módulos de assinatura digital podem ser configurados para assinar certas partes de dados DNS de acordo com um protocolo DNSSEC, sem assinar uma zona inteira.
Em modalidades, o servidor de assinatura pode também ser configurado para fornecer uma função de assinatura digital não DNSSEC adicional.
Em modalidades, cada um dos módulos de assinatura digital pode incluir um Módulo de Suporte de Hardware (HSM), que está fisicamente separado do processador do servidor de assinatura e que é configurado para assinar digitalmente dados fornecidos pelo servidor de assinatura.
Em modalidades, o HSM pode incluir uma pluralidade de chaves identificadas por identificadores de pseudônimos. O servidor de assinatura pode ser configurado para transmitir um identificador de pseudônimo para uma chave apropriada para ser usada, tal como pelo menos uma de uma KSK e uma ZSK para os dados DNS para o módulo de assinatura digital, sem passar a pelo menos uma KSK e ZSK para o módulo de assinatura digital.
Em modalidades, o servidor de assinatura pode ser configurado para verificar periodicamente um banco de dados de chaves ativas, por exemplo, KSKs ou ZSKs ativas, e para determinar quais os identificadores de pseudônimos são ativos por um tempo determinado com base em informações recebidas do banco de dados. Em modalidades, o identificador de pseudônimo passado para o módulo de assinatura digital pode ser identificador de pseudônimo ativo.
Em modalidades, o servidor de assinatura pode ser configurado para identificar um HSM especifico para enviar os primeiros dados para, com base na pelo menos uma KSK ativa e / ou ZSK ativa.
Em modalidades, o servidor de assinatura pode ser configurado para processar solicitações em relação a domínios sob diferentes TLDs.
Em modalidades, o servidor de assinatura pode ser configurado para processar solicitações em relação a pelo menos dois domínios administrados por uma pluralidade de registradores.
Em modalidades, as comunicações entre o cliente e o servidor de assinatura podem ser realizadas, por exemplo, através de SSL de duas vias.
Como foi discutido aqui, os servidores de assinatura exemplares poderão apoiar várias operações de assinatura de operações DNS, incluindo, por exemplo, funções de assinatura DNSSEC, outros serviços DNS gerenciados, assinatura remoto, assinaturas de zona de raiz e afins, implementados por uma miríade de diferentes sistemas. Em modalidades, servidores de assinatura de exemplares podem ser configurados para suportar, por exemplo, assinatura de gravações de DNSSEC afetadas como parte de uma única transação, ou seja, uma unidade atômica, consistente, isolada e durável de trabalho, aspectos que podem ser aqui referidos como "assinatura em linha".
Características adicionais, vantagens e modalidades da invenção podem ser estabelecidas ou aparentes a partir da consideração da seguinte descrição detalhada, desenhos e reivindicações. Além disso, é para ser entendido que tanto a síntese do exposto da invenção e a descrição detalhada seguinte são exemplares e destinam-se a fornecer mais explicações, sem limitar o âmbito da invenção reivindicada. A descrição detalhada e os exemplos específicos, contudo, indicam apenas modalidades preferidas da invenção. Várias alterações e modificações dentro do espírito e do âmbito da invenção se tornarão evidentes para os peritos na arte a partir desta descrição detalhada.
BREVE DESCRIÇÃO DOS DESENHOS
Os desenhos anexos, que são incluídos para proporcionar um melhor entendimento da invenção, são incorporados em e constituem uma parte desta especificação, ilustram modalidades da invenção e, juntamente com a descrição detalhada serve para explicar os princípios da invenção. Nenhuma tentativa é feita para mostrar detalhes estruturais da invenção mais detalhadamente do que pode ser necessário para uma compreensão fundamental da invenção e várias maneiras em que ela pode ser praticada. Nos desenhos: A Figura 1 mostra detalhes de um sistema de assinatura DNSSEC habilitado exemplar de acordo com aspectos da invenção. A Figura 2 mostra mais detalhes de um sistema de assinatura DNSSEC habilitado de acordo com aspectos da invenção. A Figura 3 representa um protocolo de solicitação de assinatura exemplar de acordo com aspectos da invenção. A Figura 4 representa um protocolo de dados de solicitação de assinatura exemplar de acordo com aspectos da invenção. A Figura 5 representa um outro protocolo de dados de solicitação de assinatura exemplar de acordo com os aspectos da invenção. A Figura 6 representa um protocolo de resposta de assinatura exemplar de acordo com aspectos da invenção. A Figura 7 representa um protocolo de dados de resposta de assinatura exemplar de acordo com aspectos da invenção. A Figura 8 representa um outro protocolo de dados de resposta de assinatura exemplar de acordo com aspectos da invenção. A Figura 9 mostra relações de solicitações, dados de solicitações, respostas, e dados de resposta exemplares de acordo com aspectos da invenção. A Figura 10 mostra mais detalhes de um sistema de assinatura DNSSEC habilitado exemplar, incluindo um gerenciador de agrupamento de cliente de serviço de assinatura, de acordo com aspectos da invenção. A Figura 11 ilustra um arranjo de sistema esquemático para uma técnica de assinatura em linha exemplar para assinatura DNSSEC que pode ser suportado de acordo com aspectos da invenção. A Figura 12 representa uma arquitetura de rede exemplar computador como pode ser utilizada em modalidades da invenção.
DESCRIÇÃO DETALHADA DA INVENÇÃO
Entende-se que a invenção não está limitada à metodologia, protocolos particulares, etc, aqui descritos, uma vez que estes podem variar como o perito na arte irá reconhecer. É também para ser compreendido que a terminologia utilizada aqui é usada para o propósito de descrever apenas modalidades particulares, e não se destina a limitar o âmbito da invenção. É também para ser notado que como aqui utilizado e nas reivindicações anexas, as formas singulares "a" e "um" incluem a referência plural a menos que o contexto claramente indique o contrário. Assim, por exemplo, uma referência a "um servidor" é uma referência a um ou mais servidores e seus equivalentes conhecidos dos peritos na arte. A menos que definido em contrário, todos os termos técnicos aqui utilizados têm o mesmo significado que normalmente entendido por um vulgar perito na arte à qual a invenção diz respeito. As modalidades da invenção e as várias características e detalhes vantajosos da mesma são explicados mais detalhadamente com referência às modalidades não limitativas e exemplos que são descritos e / ou ilustrados nos desenhos anexos e detalhados na descrição seguinte. Deve notar-se que as características ilustradas nos desenhos não estão necessariamente desenhadas em escala, e as características de uma modalidade podem ser empregadas com outras modalidades como o perito na arte reconhecerá, mesmo se não for expressamente aqui descrito. As descrições de componentes bem conhecidos e técnicas de processamento podem ser omitidas de modo a não obscurecer desnecessariamente as modalidades da invenção. Os exemplos aqui utilizados são destinados apenas a fim de facilitar uma compreensão das formas em que o invento pode ser praticado e para continuar a permitir que os peritos na arte pratiquem as modalidades da invenção. Assim, os exemplos e modalidades aqui não devem ser interpretados como limitando o âmbito da invenção, que é definido apenas pelas reivindicações anexas e as leis aplicáveis. Além disso, deve ser notado que números de referência semelhantes fazem referência a partes semelhantes ao longo das várias vistas dos desenhos.
Como é aqui utilizado, salvo limitado, um registrador pode ser entendido como qualquer entidade ou organização que interage com um registro de nome de domínio e permite inscritos criar e atualizar recursos de nomes de domínio.
Como é aqui utilizado, salvo limitado, um inscrito pode ser entendido como qualquer pessoa ou organização que interage com um registrador para criar e atualizar um recurso de nome de dominio.
Como é aqui utilizado, salvo limitado, um provedor de hospedagem DNS pode ser entendido como qualquer entidade ou organização que hospeda o conteúdo em seus servidores em nome de um titular, fornecendo provisionamento DNS e capacidades de resolução para tal conteúdo (por exemplo, atribuir endereço IP e operar servidores de nomes capazes de determinar nomes de dominio para esses endereços IP que ele gerencia).
Modalidades da invenção podem proporcionar técnicas de assinatura DNSSEC acessíveis por rede para permitir provedores DNSSEC de larga escala, tais como registros, para processar grandes números de alterações de DNS, incluindo dados de assinatura DNSSEC, a partir de várias fontes de uma maneira eficiente e coerente.
Visão Geral de Assinatura de Zona Como descrito acima, DNSSEC foi projetado para lidar com envenenamento de cachê e um conjunto de outras vulnerabilidades do DNS, como uma ataque por homem e modificação de dados não autorizada em servidores autorizados. Seu objetivo principal é fornecer autenticação da origem e proteção da integridade de dados DNS. A infraestrutura de chave pública (PKI) pode ser usada como meio de distribuição de chave pública. DNSSEC provê um mecanismo de verificação para dados DNS e não é um mecanismo de criptografia. Ela permite um resolvedor de segurança consciente verificar se os dados de zona que foi recebido é assinado pelo administrador da zona que detém a chave privada.
O Registro de recursos DNSKEY
Uma zona pode ter um ou mais pares de chaves, cada um dos quais inclui chave privada e chave pública. As chaves privadas podem ser armazenadas com segurança em um banco de dados de nome de domínio e usadas para assinar dados de zona. As chaves públicas podem ser armazenadas no banco de dados e também armazenadas nos dados de zona assinados como gravações de recurso DNSKEY. As chaves públicas são utilizadas para verificar os dados de zona. Gravações DNSKEY normalmente têm os seguintes dados: Bandeiras: "Chaves de Zona" e "Ponto de Entrada Seguro" Protocolo: valor fixo de 3 (para compatibilidade com versões anteriores) Algoritmo: 0 algoritmo de criptografia de chave pública.
Chave pública: dados de chave pública.
Um registro de recurso DNSKEY ("RR") pode ser tanto uma Chave de Assinatura de Zona (ZSK) ou uma Chave de Assinatura de Chave (KSK). As chaves de assinatura de chaves (KSKs) terão uma bandeira SEP definida de modo que elas podem ser distinguidas das ZSKs no RRset DNSKEY. As chaves de assinatura de chaves (KSKs) são usadas para assinar outras gravações de recurso DNSKEY e são usadas para construir uma cadeia de autoridade para os dados que precisam ser validados.
O registro de recurso RRSIG O registro de recurso RRSIG tem a assinatura DNSSEC de um conjunto de registro de recurso RRset (um ou mais gravações DNS com o mesmo nome, classe e tipo) . Resolvedores DNSSEC habilitados podem verificar a assinatura com uma chave pública armazenada em um registro DNSKEY. As gravações RRSIG têm os seguintes dados: Tipo coberto: tipo de registro DNS que esta assinatura cobre.
Algoritmo: algoritmo criptográfico usado para criar a assinatura.
Marcadores: Número de marcadores no nome gravações RRSIG original (usado para validar curingas) . TTL original: valor TTL do conjunto de gravações coberto.
Expiração de Assinatura: Quando a assinatura expira.
Inicio de Assinatura: Quando a assinatura foi criada.
Etiqueta de chave: Um valor numérico curto que pode ajudar a identificar rapidamente o registro DNSKEY, que pode ser usado para validar essa assinatura.
Nome do signatário: Nome do registro DNSKEY que pode ser usado para validar essa assinatura.
Assinatura: assinatura criptográfica.
Os RRs DNSKEY são assinados por ambas as KSKs e ZSKs ativas. Outros conjuntos de RR são assinados por apenas ZSKs ativas.
O registro de recurso NSEC O registro de recurso NSEC lista duas coisas distintas: o nome do novo proprietário (na ordem canônica da zona) que contém dados autorizados ou um ponto de delegação NS RRset, e o conjunto de tipos RR apresenta no nome do proprietário do RR NSEC (RFC3845) . O conjunto completo de RRs NSEC na zona indica que conjuntos de RR autorizado existem em uma zona e também formam uma cadeia de nomes de proprietários autorizados na zona. Essas gravações podem ser usadas por resolvedores para verificar a não existência de um nome de registro e tipo como parte da validação DNSSEC. Registros NSEC têm os seguintes dados: Próximo nome de domínio: O próximo nome de registro na zona (ordem de classificação DNSSEC) Tipos de registros: Os tipos de registros DNS que existem para o nome deste registro NSEC. O registro de recurso NSEC3 O registro de recurso NSEC3 (RR) fornece negação autenticada de existência para Conjuntos de Registros de Recurso DNS. Os RRs NSEC3 têm a mesma funcionalidade que RR NSEC, exceto NSEC3 usa nomes de registro "hashed" criptograficamente para evitar enumeração dos nomes de registro em uma zona. Um registro NSEC3 liga para o próximo nome de registro na zona (na ordem de classificação de nome desordenada) e relaciona os tipos de registros que existem para o nome coberto pelo valor hash no primeiro marcador do nome de proprietário do registro NSEC3. Esses registros podem ser usados por resolvedores para verificar a não existência de um nome e tipo de registro como parte da validação DNSSEC. Registros NSEC3 têm os seguintes dados: Algoritmo Hash: 0 algoritmo hash de criptografia usado.
Bandeiras: "Opt-out" (indica se as delegações são assinadas ou não).
Iterações: Quantas vezes o algoritmo hash é aplicado.
Salto: Valor de salto para o cálculo hash.
Próximo nome de proprietário "hashed": O nome do próximo registro na zona (em ordem de classificação de nome "hashed").
Tipos de Registro: Os tipos de registros que existem para o nome coberto pelo valor hash no primeiro marcador do nome de proprietário do registro NSEC3.
Aspectos de um arranjo servidor de assinatura exemplar são mostrados na Figura 1. Como mostrado na Figura 1, um registro, ou outro provedor de serviços DNSSEC, pode incluir qualquer número de Servidores de Assinatura 142, 146. Por exemplo, uma pluralidade de servidores de assinatura poderá estar incluindo um sistema de fornecimento de registro. Servidores de Assinatura 142, 146 podem incluir Módulos de Suporte de Hardware (HSMs) 144,148, respectivamente, e / ou software, que podem incluir a funcionalidade de assinatura digital real incluindo adequadas chaves de assinatura digital. Servidores de Assinatura 142, 146 podem comunicar, e, por exemplo, trocar e dados DNS assinados e não assinados, com várias aplicações, serviços e ferramentas 110, 120 e 130. Cada CAS 110, Serviços de Negócios de Plugin NCC 120, e componente de Lote / Ferramenta 130 terá conectividade com o servidor de assinatura (de preferência para um conjunto de tais servidores) . Servidores de Assinatura 142, 146 podem persistir dados DNS assinados para um banco de dados 150 . Detalhes adicionais de um fluxo de dados exemplar entre as aplicações, servidores de assinatura, HSMs e bancos de dados são mostrados na Figura 2.
Como mostrado na Figura 2, o cliente 210 pode representar, por exemplo, um serviço de extremidade frontal de um sistema de fornecimento, que pode ser configurado para identificar dados DNSSEC que precisam ser assinados por um servidor de assinatura 212. Os dados a serem assinados podem ser, por exemplo, uma porção de dados de zona afetados por uma mudança DNS, por exemplo, adicionar, atualizar, excluir comando para um dominio. Os dados DNSSEC, ou outros, a serem assinados podem ser analisados ou de outra forma identificados com base em, por exemplo, um comando de dominio, e fornecidos para o servidor de assinatura 212, como mostrado pelo enlace 241. A comunicação entre o cliente 210 e o servidor de assinatura 212 pode ser, por exemplo, por túnel SSL de duas vias. Informações tais como bytes, tipo de chave (ZSK, KSK) e TLD podem ser incluídas na solicitação. O servidor de assinatura 212 pode identificar a informação de chave apropriada e / ou HSM da transmissão 241, e passar os dados não assinados para o HSM apropriado 214, mostrado pelo enlace 242. Isto pode incluir um comando de assinatura com, por exemplo, os bytes, pseudônimo de chave, e algoritmo de assinatura.
Em modalidades, o servidor de assinatura 212 pode também receber, como parte da mesma solicitação de assinatura, uma solicitação para assinar outros dados. O servidor de assinatura 212 pode determinar informações chave apropriadas para os outros dados. Em modalidades e, como descrito adicionalmente, a informação de chave para os outros dados pode ser diferente do que a informação de chave para os primeiros dados incluídos na mesma solicitação de assinatura.
Solicitações 241 do cliente 210 para o servidor de assinatura 212 podem ser formatadas de acordo com um Protocolo de Servidor de Assinatura (SSP). Em modalidades, protocolos exemplares podem incluir um formato "vagão", em que várias solicitações de assinatura podem ser empacotadas em uma única solicitação de protocolo, otimizando assim em desempenho-degradação utilização de largura de banda e ida e volta de rede. Além disso, o SSP pode incluir um recurso embutido de diagnóstico que cada módulo de serviço pode aderir para permitir clientes para determinar o estado de disponibilidade e os problemas recentes do serviço. Em modalidades, os protocolos aqui descritos podem permitir, entre outros objetivos, capacidade de conexão imediata de novas formações de pacotes de transferência de dados requeridas por módulos de serviço novos adicionados ao servidor de assinatura sem uma mudança para o protocolo de transferência propriamente dito. Um SSP exemplar é mostrado na Figura 3, e descrito mais abaixo.
Como mostrado na Figura 3, um Protocolo de Solicitação de Servidor de Assinatura 300 a partir de um cliente pode incluir campos para: Comprimento de Pacote : : = int (comprimento total do pacote) Versão de Protocolo:: = byte (Versão do Protocolo) Tipo de Serviço :: = byte (por exemplo, Simples (para assinatura genérica); DNSSEC (para assinatura DNSSEC); recuperação de chave pública (dada um pseudônimo de chave, retorna a chave pública)).
Id de Transação :: = Long (Id único para reconhecer a solicitação) Bandeiras : : = int (Campo que permite solicitações passar em bandeiras (serviço agnóstico).
Id de sessão : : = Long (O Id de sessão enviando a solicitação, pode ser utilizado para fins de auditoria).
Id de Conta: : = Long (O Id de conta enviando a solicitação, pode ser utilizado para fins de auditoria). Número de Registros : : = byte (Número de dados de solicitação (ou seja, o número de pacotes contidos na solicitação global em que o serviço precisa tomar medidas)) Dados de Solicitação de Assinatura 1 ... n - Pacote (s) de dados em que o serviço precisa agir, normalmente, o que inclui dados a ser assinados.
Cliente 210 pode enviar Dados de Solicitação de Assinatura como cargas dentro de suas solicitações 300. Em modalidades, um servidor de assinatura 212 pode ser configurado para reconhecer e agir sobre as solicitações de serviços diferentes e para interpretar as cargas de dados baseado em, por exemplo, um codec associado. Em modalidades, os dados podem ser estruturados de várias formas, que podem ser referidas como "Protocolos de Dados de Solicitação de Assinatura", incluindo, por exemplo, SimpleSigningRequestData, RRSigSigningRequestData, ou PublicKeyRetrievalRequestData, discutidos mais adiante. A Figura 4 mostra um exemplo de um Protocolo de Dados de Solicitação de Assinatura. Como mostrado na Figura 4, uma Solicitação de Assinatura Simples 310 podem incluir: Comprimento :: = int (Comprimento dos dados) Algoritmo :: = String (Algoritmo de Assinatura) Pseudônimo de chave :: = String (Pseudônimo de chave que precisa ser utilizado para assinatura) Comprimento de Dados de Solicitação : : = int (Comprimento do campo de Dados de Solicitação) Dados de Solicitação : : = byte (Os dados que precisam ser assinados por Servidor de Assinatura) Como mencionado acima, o cliente 210, servidor de assinatura 212 e HSM 214 podem utilizar pseudônimos de chave para identificar as chaves especificas. Assim, os vários componentes não precisam de troca chaves reais, o que pode ser vantajoso em manter a segurança de material de chave, particularmente chaves que possam ser mantidas em um componente particular, por exemplo, o HSM 214, em um estado essencialmente inacessível (isto é, não é acessível através da rede).
Um RRSigSigningRequestData, tal como mostrado na Figura 5, pode ser usado para implementar os Dados de Solicitação de Assinatura, de uma maneira semelhante à SimpleSigningRequest. O RRSigSigningRequestData pode ser, por exemplo, um grão de dados, preenchido pelo cliente, segurando informações sobre o registro RRSIG que precisa ser assinado. Como discutido mais adiante, cada classe de solicitação pode ser retornada pelo servidor de assinatura 212 como uma resposta correspondente 244. Deve ser notado que, quando o servidor de assinatura 212 recebe uma solicitação 241, isto pode aumentar os dados de solicitação com dados relacionados DNSSEC, ou outros dados, seus.
Um RRSigSigningRequestData 320 pode incluir: Comprimento :: = int (Comprimento dos dados) Id RRSIG : : = Long (Id único ou o RRSigSigningRequestData) Nome de Domínio :: String = (O nome de domínio) Id de Domínio :: = Long (O Id do domínio) Domínio Pai :: = String (O domínio pai) Tipo Coberto :: = int (O Tipo Registro de Recurso) Número de Marcadores :: = int (O número de marcadores no nome de domínio) Orig TTL :: = Long (Os dados que precisam ser assinados por Servidor de Assinatura) TTL :: = Long (Os dados que precisam ser assinados por Servidor de Assinatura) Tempo de Início RR : : = Long (Um tempo de época do tempo de início RRSIG) Comprimento de Bytes RRSet : : = int (Comprimento dos Bytes RRset) Bytes RRset : : = byte (Os dados que precisam ser assinados por Servidor de Assinatura) Por conseguinte, considerando-se a combinação do Protocolo de Solicitação de Assinatura de Servidor 300 mostrado na Figura 3, o SimpleSigningRequestData 310 mostrado na Figura 4, e o RRSigSigníngRequestData 320 mostrado na Figura 5, adequadamente configurados servidores de assinatura podem aceitar uma solicitação de assinatura única (por exemplo, através de Protocolo de Solicitação de Servidor de Assinatura 300) com múltiplos Dados de Solicitação de Assinatura, cada Dado de Solicitação de Assinatura tendo algoritmos de assinatura potencialmente diferentes, pseudônimos de chave, etc. Como ainda descrito aqui, no caso de dados RRSigning, algoritmos apropriados e / ou chaves podem ser baseados, por exemplo, em domínios identificados e / ou TLDs associados com a solicitação. Em modalidades, o servidor de assinatura pode ser configurado para processar solicitações em relação a domínios sob TLDs diferentes, e / ou processar solicitações em relação a pelo menos dois domínios administrados por uma pluralidade de registradores, através da análise das solicitações e pacotes de dados aqui descritos.
Protocolo de Dados de Solicitação de Assinatura pode também incluir um PublicKeyRequestData (não mostrado) incluindo os seguintes campos: Comprimento :: = int (Comprimento dos dados) Pseudônimos de chave :: String (0 Pseudônimo de chave para recuperar a Chave Pública) O servidor de assinatura 212 pode ser configurado para verificar com o banco de dados 220 para os dados autorizados sobre os quais pseudônimo de chave usam quando enviando dados para o HSM 214. 0 servidor de assinatura 212 poderá também ser configurado para identificar um HSM especifico para enviar os pacotes de dados baseado em uma KSK ativa e / ou ZSK ativa. O HSM 214 pode ser carregado com muitas chaves por TLD no momento da inicialização (algumas podem ser ZSKs, algumas podem ser KSKs) e cada chave pode ser conhecida para o HSM 214 por um pseudônimo, keyAlias. O cliente 210 pode configurado para contar ao servidor de assinatura 212 qual dos dois tipos de chave a ser usado (ZSK ou KSK) e o TLD, e o servidor de assinatura 212 pode ser configurado para identificar o nome de pseudônimo de chave atual para esse tipo de chave quando ele se comunica com o HSM para assinatura. O servidor de assinatura 212 também pode ser forçado a voltar a verificar com o banco de dados 220 para os pseudônimos de chave atuais. Este comando pode ser emitido, por exemplo, para o servidor de assinatura 212 através de uma interface de gestão JMX. Assim, o servidor de assinatura 212 pode ser entendido como "DNSSEC consciente".
Uma vantagem de fazer o servidor de assinatura DNSSEC consciente é salvar a organização e desorganização de dados que o cliente de outra forma teria que passar com quase todas as solicitações de assinatura, ainda que esses dados não mudem. Ou seja, dados que não mudam com freqüência, não precisam ser conhecidos pelo cliente 210 ou enviados pelo cliente 210 com cada pedido 241. Em vez disso, esses dados podem ser conhecidos por e salvos em cachê pelos servidores de assinatura 212 em si. O servidor de assinatura 212 poderá também ser configurado para fornecer capacidades de assinatura genéricas também. Exemplos podem incluir a configuração do servidor de assinatura para uso com um serviço DNS Gerenciado que tem um grande número de chaves e zonas (milhares ou milhões) para criar várias assinaturas para serviços DNS gerenciados, assinatura de zona de raiz, etc. Em modalidades, o cliente pode ser configurado para fornecer parâmetros de assinatura juntamente com a capacidade de carregar e descarregar dinamicamente chaves usadas para assinatura. O servidor de assinatura de "assinatura genérica" capaz de executar vários tipos de transações de assinatura pode fornecer uma aplicação flexível para uso com, por exemplo, um serviço DNS gerenciado de grande escala multifunções. Assim, o servidor de assinatura 212 pode ser DNSSEC consciente, e capaz de trabalhar para outros fins de assinatura, por exemplo, através de plugins configuráveis em execução (serviços) que o servidor pode confiar para lidar com solicitações de entrada. De acordo com aspectos da invenção, a estrutura de servidor de assinatura, tal como mostrado na Figura 2, pode permitir que diferentes partes escrevam módulos de serviço, incluindo diferentes parâmetros e chaves, o que pode comunicar com vários tipos de aplicações de assinante de software ou hardware. Outras funções podem ser adicionadas ao protocolo para suportar novas funcionalidades, sem interferir com os clientes existentes. As configurações do servidor de assinatura e os protocolos de servidor de assinatura poderão permitir, por exemplo, uma aplicação DNSSEC para incluir outras diversas interfaces de usuário final definidas (por exemplo, serviços da Web, EPP, REST), sem afetar a assinatura básica.
Modalidades podem incluir uma base de código de servidor de assinatura com módulos de serviços que fornecem uma combinação de parâmetros de configuração de assinatura de cachê e não cachê. Módulos de serviço podem, assim, voltar a usar esses recursos de cachê e não cachê dependendo de suas necessidades. Cachê pode ser utilizado para aumentar desempenho para módulos de serviço que têm chaves relativamente estáveis e configurações de assinatura, ao passo que não cachê pode facilitar o carregamento de chaves e parâmetros de assinatura sob demanda para situações que requerem grandes volumes de chaves e parâmetros armazenados offline e ativados apenas no momento da assinatura. Além disso, quando módulos de serviço individuais funcionam mal ou se tornarem indisponíveis, como pode acontecer com diferentes protocolos e chaves, o servidor de assinatura por si só pode manter-se robusto e permitir que seus outros módulos continuem atendendo a solicitações. Essa flexibilidade pode oferecer inúmeras opções que não são realizáveis, por exemplo, pelas aplicações de assinatura DNSSEC autônomas atuais.
Uma vantagem particular da abordagem não cachê, por exemplo, onde todas as chaves aplicáveis não são salvas em cachê no HSM ou outro módulo de assinatura, é que as chaves que são digitalmente embrulhadas podem ser armazenadas em um repositório disponível menos caro e maior, tal como banco de dados que é fácil de se replicar em centros de dados e semelhantes. O HSM ou outro módulo de assinatura pode então recuperar as chaves, conforme necessário, para assinar dados. Tal armazenamento separado, e carregamento quando necessário, de chaves atuais foi encontrado pelos inventores para permitir um serviço de assinatura global tal como aqui descrito para dimensionar a um número muito maior de chaves, sem sacrificar a capacidade de desempenho de um HSM ou a disponibilidade do banco de dados utilizado. Isto tem sido encontrado como sendo particularmente útil no contexto de serviços DNS enormemente escalados, como pode ser fornecido por um registro, que pode necessitar acessar chaves para milhares a milhões de zonas.
Em modalidades, um HSM ou outro módulo de assinatura, pode criptografar chaves relevantes armazenadas em um banco de dados com uma chave privada do HSM ou outro módulo de assinatura. Conforme descrito aqui, cada chave pode ser identificável através de um keyAlias, e pode ser descodificada pelo HSM ou outro módulo de assinatura utilizando a chave privada, quando recuperada.
Voltando à Figura 2, o HSM 214 pode assinar os dados DNSSEC como recebidos, por exemplo, na solicitação 242, com uma chave apropriada, e passar os dados assinados de volta para o servidor de assinatura 212 como mostrado pelo enlace 243. Em modalidades, tais assinaturas podem ser baseadas em, por exemplo, a identificação de chaves adequadas e / ou protocolos de pseudônimos de chave e semelhantes incluídos na solicitação. Alternativamente, HSMs, ou outras aplicações de assinatura de software, podem ter chaves e / ou parâmetros pré-determinados para aplicar às solicitações de assinatura dirigidas a eles. Deve notar-se que, de acordo com aspectos da invenção, incluindo os pacotes de dados separadamente Identificados contidos na solicitação de assinatura, os pacotes podem ser processados de forma assincrona de modo que o cliente pode continuar processando sem bloquear a resposta de assinatura. Além disso, um servidor de assinatura único pode receber e agir sobre solicitações para assinar dados através de aplicações e em diferentes zonas simultaneamente. Ou seja, o único servidor pode receber em um único pacote de solicitação comandos para assinar dados que não são relacionados uns aos outros, através de zonas e / ou aplicações.
Além disso, o servidor de assinatura 212 pode ser configurado para solicitar e fornecer várias assinaturas para um único pacote de dados. Por exemplo, o servidor de assinatura 212 pode reconhecer mais do que uma chave ativa e / ou algoritmo a ser aplicado a certos dados e pode requerer uma pluralidade de assinaturas a partir do HSM ou outro módulo de assinatura com base em mais do que uma chave ativa e / ou algoritmo. Em modalidades, o servidor de assinatura 212 pode ser configurado para solicitar e reportar a assinatura de, por exemplo, primeiros dados com uma primeira chave por um primeiro algoritmo, e os primeiros dados com uma segunda chave por um segundo algoritmo. Várias chaves ativas e as assinaturas podem ser aplicadas, por exemplo, de acordo com requisitos do usuário, no contexto de sobreposições de chave e / ou para DNSSEC para realizar eficazmente uma lista de algoritmo (por exemplo, SHA-1 para SHA-2). 0 HSM 214 pode ser fisicamente separado a partir do processador do servidor de assinatura 212, e pode incluir, por exemplo, os protocolos de segurança adicionais para salvaguardar as chaves no HSM 214. Por exemplo, o HSM 214 pode ser configurado para trocar determinadas informações de chave apenas através de procedimentos de carga físicos para salvaguardar chaves no mesmo, particularmente aquelas com longa vida de serviço ou uma ampla aplicabilidade, por exemplo, KSKs. Em modalidades, o HSM pode incluir uma ou mais chaves, e um ou mais identificadores de pseudônimos que identificam as chaves armazenadas no mesmo. O servidor de assinatura 212 pode passar dados assinados, por exemplo, DNSSEC ou outros dados assinados digitalmente, ou outros dados, como informações de confirmação de transação, de volta ao cliente 210 como mostrado pelo enlace 244.
Como notado acima, cada classe de solicitação pode ser retornada pelo servidor de assinatura 212, como uma resposta correspondente 244. A resposta 244 retornada pelo servidor de assinatura 212 pode ser configurada para seguir um Protocolo de Resposta de Servidor de Assinatura como mostrado na Figura 6.
Como mostra na Figura 6, o Protocolo de Resposta de Servidor de Assinatura 400 pode incluir, por exemplo: Tamanho do pacote : : = int (Comprimento total do pacote) Versão de Protocolo : : = byte (Mesmo que foi enviado na solicitação) Tipo de Serviço :: = byte (Mesmo que o que foi enviado na solicitação) Id de Transação : : = tempo (Mesmo que o que foi enviado na solicitação) Bandeiras :: = int (Campo que permite as solicitações passarem em bandeiras (serviço agnóstico). Código de resposta : : = byte (O código de resposta após o processamento da solicitação). Veja abaixo os códigos de resposta que podem ser retornados através do Servidor de Assinatura.) Comprimento de Mensagem de Resposta :: = int (O comprimento da mensagem de resposta detalhada para a resposta retornada pelo servidor.) Caracteres de Mensagem de Resposta : : char (Os caracteres de mensagens de resposta). Número de Registros : : - byte (Número de dados de resposta (ou seja, número de pacotes contidos na solicitação global em que o serviço precisa tomar medidas)) Dados de Resposta de Assinatura 1 ... n. Códigos de Resposta de Assinatura Exemplar são apresentados na tabela 1: Tabela 1 Os Dados de Resposta de Assinatura poderão incluir, por exemplo, SimpleSigningResponseData, RRSigSigingResponseData, ou publcKeyRetrievalResponseData, correspondente à Solicitação, ou seja, SimpleSingningRequestData, RRSigSigingRequestData, ou PublickeyRetrievalRequestData. Em modalidades, pode haver uma objeto de dados de resposta para cada pacote de solicitação de dados enviado na solicitação.
Um exemplo de SimpleSingningResponseData 410 é mostrado na Figura 7, tal como seria retornado, por exemplo, através do servidor de assinatura 212 como resposta a um simpleSigningRequest, tal como mostrado na Figura 4. Como mostrado na Figura 7, os campos do SimpleSigningResponseData 410 podem incluir: Comprimento :: = int (Comprimento dos dados) Comprimento de Dados Assinados : : = int (Comprimento do Campo de Dados Assinados) Dados Assinados : : = byte (Os dados que precisam ser assinados por Servidor de Assinatura) A Figura 8 mostra um exemplo de um RRSigSigingResponseData 420, que pode ser utilizado para cada pacote de resposta de dados resultante de uma solicitação relacionada RRSIG, tal como mostrado na Figura 5. Os campos RRSigSigingResponseData 420 podem incluir: Comprimento :: = (Comprimento dos dados) Id RRSIG : : = Long (Id único do RRSigSigingRequestData) Nome de Domínio :: String = (O nome de domínio) Id de Domínio :: = Long (O Id do domínio) Domínio de Pai :: = String (O domínio do pai) Tipo Coberto :: = int (o tipo Registro de Recurso) Número de Marcadores : : = (O número de marcadores no nome de domínio) Orig TTL :: = Long (Os dados que precisam ser assinados por Servidor de Assinatura) TTL :: = Long (Os dados que precisam ser assinados por Servidor de Assinatura) Tempo de Início RR : : = Long (0 tempo de época do tempo de início RRSIG) Etiqueta de chave : : = int (A etiqueta de chave da Chave que foi usada para assinar a solicitação) Id de algoritmo : : = int (O Id de Algoritmo que foi usado para assinar a solicitação) Assinatura : : = String (A Assinatura codificada em base 64 gerada por assinar a solicitação) Tempo Final RR: : (0 tempo de época do tempo final RRSIG) Os dados de resposta de assinatura podem também incluir um PublicKeyResponseData (não mostrado), incluindo os seguintes campos: Comprimento :: = int (Comprimento dos dados) Pseudônimo de chave :: = String (0 pseudônimo de chave enviado na solicitação) Chave Pública : : = String (A Chave Pública codificada em base 64 da chave recuperada usando o pseudônimo de chave) Uma vez que os dados assinado são retornados para o cliente 210, o cliente pode distribuir os dados assinados como requerido, por exemplo, para o DNS ou outro serviço, e / ou enviar mensagens de confirmação conforme necessário. Em modalidades, o cliente 210 pode ser configurado como uma aplicação DNSSEC que pode identificar e agir sobre alterações DNS e semelhantes, bem como determinar as funções DNSSEC apropriadas que precisam ser realizadas. Assim, o servidor de assinatura 212 pode ser aliviado de muito da programação e funcionalidade de aplicação especifica DNSSEC. A aplicação DNSSEC, por exemplo, o cliente 210, pode se concentrar na lógica de negócios DNSSEC (quais registros de recursos precisam ser assinadas, etc) sem ter que se preocupar com as especif icidades dos parâmetros de assinatura e sem ter de arcar com os custos de rede e processamento de montagem e passagem de informação extra para o servidor de assinatura 212. Da mesma forma, como discutido acima, os vários protocolos de solicitação e resposta permitem a aplicação DNSSEC combinar todas das solicitações de assinatura relativamente menores (sem todos os vários parâmetros de assinatura DNSSEC e informação de chave) em um único pacote, reduzindo assim a carga da rede e sobrecarga. Finalmente, o cliente 210 pode também ser aliviado de qualquer um dos detalhes de interface HSM. A Figura 9 representa graficamente relações da solicitação e protocolos de resposta exemplares acima descritos como compartilhadas entre o cliente e o servidor. Deve notar-se que os protocolos descritos acima, e os conteúdos específicos, são exemplares na natureza e não limitam o âmbito da invenção a tais protocolos específicos. Por exemplo, outros protocolos podem ser implementados que aproveitam as capacidades do servidor de assinatura inteligente, por exemplo, onde a programação chave é carregada no servidor de assinatura e o cliente só tem que passar os dados para assinar junto com identificadores apropriados para o servidor de assinatura escolher automaticamente a chave certa.
De acordo com aspectos adicionais da invenção, os aglomerados de clientes e servidores de assinatura podem ser administrados para melhorar o equilíbrio de carga e capacidade de resposta dos sistemas de sinalização, como aqui descrito. Por exemplo, como mostrado na Figura 10, em modalidades, para cada servidor de assinatura 801-801n, pode haver um exemplo de um SigningServerClient 810 para manipular solicitações para o servidor de assinatura particular. Ao longo do SigningServerClient 810, pode haver também um SigningServiceClientPool 820 que gerencie instâncias SigningServerClient. O SigningServiceClientPool 820 pode ser ligado a qualquer número de SigningServerClient, e pode ser configurado para, por exemplo, equilibrar carga de solicitações para vários servidores de assinatura, por exemplo, usando "round robin", tirar uma instância SigningServerClient fora de rotação se o servidor de assinatura conectado está desligado, etc.
Cada SigningServerClient 810 pode ser configurado para manter o agrupamento de conexões de soquete 812 com os servidores de assinatura, notificar SigningServiceClientPool 820 se este serviço desliga e começar rotina de verificação de saúde, e / ou continuamente tentar se conectar ao servidor de assinatura e notificar SigningServiceClientPool 820 para colocar esse serviço de volta na rotação após o servidor de assinatura voltar a funcionar.
Assim, todo o sistema pode ajustar-se a falhas do lado do cliente e do lado do servidor. Por exemplo, o serviço do lado do cliente pode manter uma lista de servidores de assinatura e vai reagir para exceções "fatais" / respostas de erro identificadas dos servidores. O lado do cliente poderá remover esses servidores de assinatura defeituosos das rotações "round robin" e pode continuamente tentar reconhecer quando o servidor voltar a ficar online. O servidor de assinatura pode ser configurado para suportar um "ping" para que os clientes possam verificar a sua saúde.
Se o serviço de assinatura do lado do cliente descobre que todos seus servidores de assinatura estão fora de operação, ele pode retornar imediatamente exceções quando ele receber solicitações para ter algo assinado. O cliente pode continuar a fazer isso até que pelo menos um dos servidores de assinatura se encontre disponível.
Cenários de falha a partir da assinatura do lado do servidor podem incluir a não disponibilidade de uma de suas dependências, por exemplo, o HSM ou o banco de dados de chave. Se o HSM não estiver disponível, o servidor de assinatura pode relatar respostas de erro indicando isso. O servidor de assinatura pode alertar sobre essa condição através de, por exemplo, JMX e entradas de registro. O servidor de assinatura também pode continuamente tentar detectar se o HSM está de volta online. Se o banco de dados de chave torna-se indisponível para atualizações de dados de chave, o servidor de assinatura pode ser configurado para recusar solicitações para assinar dados, por exemplo, porque corre o risco de assinar com a chave errada. O servidor de assinatura pode ser configurado para relatar este erro como respostas de assinatura, e pode continuamente tentar ligar de volta para o banco de dados de chave.
Outra opção é configurar o servidor de assinatura para "cair" a conexão do cliente e / ou interromper a audição de novas conexões para um determinado serviço quando o serviço não está funcionando corretamente. Tais configurações podem ser benéficas, por exemplo, em permitir que o cliente direcione solicitações de serviço apenas a servidores de assinatura que são atualmente operáveis para realizar o serviço, melhorando o monitoramento do estado da rede de serviços de assinatura, reduzindo o número de erros relatados de volta para o cliente, e melhorando a eficiência global do cliente. Tais configurações podem também permitir que o servidor de assinatura continue com outros serviços operáveis sem o ônus de encontrar e / ou reportar erros para o serviço não funcionando até que o problema seja resolvido. Configurações semelhantes podem ser aplicadas entre o servidor da assinatura e uma pluralidade de HSMs suportando ou outros módulos de assinatura.
De acordo com as modalidades representadas nas Figuras 1, 2 e 10, e os aspectos dos protocolos de Solicitação e Resposta acima descritos, os clientes, tais como cliente 210, podem recorrer a técnicas e bibliotecas de utilidade de cliente para fornecer recursos de alta disponibilidade e balanceamento de carga. Por exemplo, bibliotecas de utilidade de cliente podem interagir com o servidor de assinatura independentemente de que módulo de serviço dentro do servidor elas estão usando. As bibliotecas de utilidade de cliente podem fornecer auto-reconexão e rápida-falha (em tempos de indisponibilidade de serviço), como parte de seus conjuntos de recursos. Os recursos de balanceamento de carga das bibliotecas de utilidade de cliente também podem ajudar a garantir que não importa quantos servidores de assinatura estão disponíveis e não disponíveis, e não importa quantos clientes estão conectados a esses servidores em qualquer tempo, a carga será de modo relativamente uniforme distribuída entre os servidores ativos automaticamente.
Em modalidades, os plugues de módulo de serviço para o servidor de assinatura pode incluir módulos para um ou mais TLDs, por exemplo, com,, net, .edu, etc. Em modalidades, vários TLDs podem ser apoiados por um único módulo de serviço que está ciente das várias programações e / ou protocolos de chave para os diferentes TLDs. Módulos de serviço podem ser configurados para fornecer, por exemplo, que ZSK deve ser usada para a geração de uma assinatura digital sob demanda, dado o TLD para o qual se aplica a assinatura e contabilidade para sobreposições de chave; que hardware ou software de assinante deve estar gerando a assinatura para tal TLD; que parâmetros específicos de TLD usar ao gerar a assinatura, incluindo o salto, algoritmo hashing, algoritmo de assinatura, duração da assinatura, etc. Em modalidades, o servidor de assinatura pode ser configurado para automaticamente e periodicamente recarregar estas configurações a partir do banco de dados para que ele possa pegar mudanças durante a operação normal sem uma reinicialização.
Uma vantagem particular desta abordagem é que pode ser fornecida uma configuração centralizada autorizada que assegura a produção de assinatura consistente por TLD. Além disso, significa que as aplicações de registro para os TLDs em si podem não ter que saber dessas políticas diretamente, mas sim, exigir que o servidor de assinatura assine dados e contam com o servidor de assinatura para aplicar as políticas necessárias e parâmetros ao fazê-lo, em uma base por TLD. Esta metodologia pode reduzir o risco do registro como um todo tornar-se fora da data em termos de dados de configuração de assinatura quando esses dados mudam durante a operação normal porque, por exemplo, pode haver muito menos servidores de assinatura do que há instâncias de aplicações registro. Além disso, os clientes para os servidores de assinatura não precisam ter uma configuração adicional e lógica de aplicação relacionada à carga de parâmetros de assinatura específicos de TLD, o que aumentaria a complexidade de aplicação e aumentaria o risco de erros de configuração, resultando em falhas de assinatura digital. Finalmente, os clientes não têm que passar para o servidor de assinatura os parâmetros de assinatura específicos de TLD com cada solicitação, o que significa carga de rede reduzida e maior rendimento.
Mais geralmente falando, de acordo com aspectos da invenção, os servidores de assinatura podem ser configurados para permitir aos desenvolvedores conectar em serviços "inteligentes", onde os serviços detêm o conhecimento sobre quais chaves estão ativas, que algoritmos devem ser usados, e assim por diante , com base no contexto da solicitação de assinatura, que por si só pode conter nenhuma desta informação. Isso pode ser preferível particularmente no contexto onde os clientes são destinados a permanecer como "burro" quanto possível. Isto pode ser usado para, por exemplo, implementar pacotes menores, reduzir as possibilidades de clientes que operam com informação ultrapassada ou não ser sincronizado com o estado das chaves, e fornecer o código de cliente frágil e menos volumoso.
Como mencionado anteriormente, a metodologia e aparelho de servidor de assinatura, tal como aqui descrito, pode encontrar aplicabilidade, e ser compatível com, uma vasta gama de DNS, e outros serviços de assinatura. Por exemplo, fornecendo um servidor de assinatura, acessível por rede, configurável, vários protocolos de assinatura remotos e configurações podem ser prontamente suportados. Um tal exemplo não limitativo que pode ser suportado inclui um arranjo de "assinatura em linha", que pode ser usado para funções de assinatura DNSSEC aqui descritas, detalhes das quais são mostrados na Figura 11. Como mostrado na Figura 11, um solicitador 1000, tal como, por exemplo, um inscrito, um registrador ou um DNS, pode comunicar com um sistema de fornecimento de registro 1100. O solicitador 1000 pode se comunicar comandos relacionados a um domínio existente ou novo. Por exemplo, solicitador 1000 pode se comunicar comandos para alterar os dados DNS gerenciados por um registrador, como os dados DNS para um dominio sob um TLD (por exemplo. com) gerenciados pelo registro. Sistema de fornecimento de registro 1100 pode processar o comando de domínio a partir do solicitador 1000 de várias maneiras incluindo, por exemplo, a execução de comandos de mudança, por exemplo, comandos de adicionar, modificar ou excluir, identificar mudanças de dados DNSSEC, identificar as chaves apropriadas, aplicar assinatura digital, persistir mudanças DNSSEC e DNS para um banco de dados de registro 1200, etc.
Dados fornecidos pelo sistema de fornecimento de registro 1100 para o banco de dados de registro 1200 podem incluir informações DNS para o domínio e dados DNSSEC assinados. Em modalidades, os servidores de assinatura exemplares podem suportar, por exemplo, um método de implementação das alterações DNS e as mudanças DNSSEC dentro de uma única transação.
Como descrito acima, a assinatura DNSSEC pode ser feita pelo servidor de assinatura, de forma síncrona em linha com a transação. Serviços separados podem ser usados para tirar cada transação confirmada no banco de dados de Registro e aplicar isso gradativamente para os servidores DNS .
Assinatura DNSSEC em linha com os comandos de dominio de um registro de domínio pode proporcionar vantagens na manutenção de um nível mais elevado de integridade de dados, assegurando, por exemplo, que o banco de dados de registro representa sempre a fonte autorizada para qual é publicada em DNS.
Como parte da implementação da assinatura em linha DNSSEC, um aglomerado de redes disponíveis e servidores de assinatura de alto desempenho, tal como mostrado nas Figuras 1 e 2, podem ser proporcionados para assinar a informação DNSSEC. Isto tem sido encontrado como sendo eficaz mesmo no contexto dos maiores TLDs, e mantém o tempo de resposta de registro de dominio do SLA, bem como a manutenção da propagação DNS do SLA com um elevado nivel de integridade de dados, mesmo quando servindo 1.000+ ligações simultâneas a partir clientes que necessitam de assinaturas digitais.
Modalidades da presente invenção podem incluir sistemas para implementação dos métodos descritos, bem como meio de armazenamento legível pelo computador codificado com instruções para fazer um computador executar os métodos descritos. Por exemplo, como mostrado na Figura 12, sistemas de servidor, como servidor 600, 610, e / ou 620, incluindo pelo menos um processador, uma memória e um dispositivo de comunicação eletrônico (não mostrado), pode ser configurado para receber, identificar, responder e / ou atuar sobre um pedido, tais como os aqui descritos, recebidos através da rede 605, tal como Internet. Qualquer um dos servidores 600, 610, e / ou 620 pode ser operado por, por exemplo, um provedor de hospedagem de Internet, um registrador, e / ou um registro como descrito adicionalmente aqui, e pode estar em comunicação com qualquer número de servidores DNS recursivos geralmente representados por dispositivos web 630. Tal como aqui descrito, os servidores recursivos 630 podem armazenar em cachê dados relacionados a DNS para domínios dos provedores de hospedagem, registradores, e / ou servidores de operação de registros 600, 610 e 620.
Solicitações para atualizar os dados DNS para um domínio podem ser originárias de, por exemplo, um registrador, provedor de serviço DNS, ou inscrito, através de vários sistemas, como, por exemplo, computadores 611, 612, via servidor separado 613 que pode ser sem fio ou outra comunicação com o dispositivo móvel (s) 614, dispositivos de rede de pico célula 615, computador móvel 61, ou qualquer outro dispositivo com capacidade de rede com outras capacidades funcionais necessárias.
As diversas comunicações, transmissões, e funções relacionadas descritas aqui podem ser realizadas, por exemplo, através da rede 605, e os resultados do processamento descrito realizado pelos sistemas de servidor, como servidores 600, 610 e 620, podem ser exibidos, armazenados e / ou distribuídos de acordo com técnicas conhecidas. A rede 605 pode incluir qualquer número de componentes de comunicação, incluindo enlaces com fio, celular, via satélite, ópticos e / ou enlaces de comunicação similares.
Os servidores 600, 610 e 620, e os computadores 611, 612, podem incluir qualquer número de processadores (não mostrado) que são acoplados a dispositivos de armazenamento, incluindo um primeiro armazenamento (não mostrado, tipicamente uma memória de acesso aleatório, ou "RAM"), segundo armazenamento (não mostrado, tipicamente uma memória somente de leitura, ou "ROM"). Ambos os dispositivos de armazenamento podem incluir qualquer tipo adequado de meios legíveis por computador, incluindo meio de armazenamento não transitório, como flash drives, discos rígidos, disquetes, fitas magnéticas, mídias ópticas, como discos CD-ROM e / ou magneto-óptico. Um dispositivo de armazenamento em massa (não mostrado) pode também ser usado para armazenar programas, dados e semelhantes e é tipicamente um meio de armazenamento secundário, tal como um disco rígido que é mais lento do que o armazenamento primário. Será apreciado que a informação retida dentro do dispositivo de armazenamento em massa pode, em casos apropriados, ser incorporada na forma padrão como parte de armazenamento principal, como memória virtual. Um dispositivo de armazenamento em massa específico, tais como um CD-ROM também podem passar dados unidirecionalmente para o processador.
Os servidores 600, 610 e 620 e computadores 611, 612, também podem incluir uma interface que inclui um ou mais dispositivos de entrada / saída, tais como monitores de vídeo, "track balis", mouses, teclados, microfones, monitores sensíveis ao toque, leitores de cartões de transdutor, leitores magnéticos ou de fitas de papel, tablets, styluses, reconhecedores de voz ou escrita, ou outros dispositivos de entrada conhecidos, incluindo outros computadores. Os servidores 600, 610 e 620, e os computadores 611, 612, podem ser acoplados a um computador ou outra rede de comunicação eletrônica 605 através de uma conexão de rede. A rede 605 pode conectar várias redes com fios, ópticas, eletrônicas e outras redes conhecidas para troca de informações entre os servidores 600, 610 e 620, e computadores 611, 612, servidor separado 613, dispositivo móvel (s) 614, dispositivos de rede de pico célula 615, computador móvel (s) 616, servidores recursivos 630, e quaisquer outros dispositivos com funcionalidade semelhante. Com uma tal conexão de rede, é contemplado que os servidores 600, 610 e 620, e computadores 611, 612 e os processadores neles podem receber informações a partir da rede 605, ou pode retornar informação para a rede 605 no curso de realizar os passos de método acima descritos. Os dispositivos e materiais acima descritos serão familiares para aqueles que são peritos nas artes de hardware e software do computador e não precisam ser individualmente ou exaustivamente descritos para serem entendidos por aqueles que são peritos na arte. Os elementos de hardware descritos acima podem ser configurados (geralmente temporariamente) para atuar como um ou mais módulos para executar as operações descritas acima.
Além disso, modalidades da presente invenção ainda incluem meios de armazenamento legíveis por computador que incluem instruções de programa ou execução de várias operações implementadas por computador tais como aqui descritas. Os meios podem também incluir, sozinhos ou em combinação com as instruções de programa, arquivos de dados, estruturas de dados, tabelas, e semelhantes. Os meios de comunicação e instruções de programas podem ser aqueles especialmente concebidos e construídos para os fins do presente assunto, ou podem ser do tipo disponível para aqueles com conhecimentos na arte de software de computador. Exemplos de meios de armazenamento legíveis por computador são meios magnéticos, tais como dispositivos de memória de somente leitura (ROM) e memória de acesso aleatório (RAM). Exemplos de instruções de programa incluem tanto o código de máquina, como o produzido por um compilador e arquivos que contenham código de nivel superior que podem ser executados pelo computador usando um interpretador. A descrição dada acima é meramente ilustrativa e não pretende ser uma lista exaustiva de todas as modalidades possíveis ou modificações e variações dos métodos descritos e sistemas da presente invenção serão evidentes para os peritos na arte sem se afastar do âmbito e espirito da invenção. Embora a invenção tenha sido descrita em ligação com modalidades específicas, deve ser entendido que a invenção tal como reivindicado não deve ser indevidamente limitada a tais modalidades específicas.

Claims (32)

1. Servidor de assinatura DNSSEC configurado para interagir com pelo menos uma aplicação cliente DNSSEC e uma pluralidade de módulos de assinatura digital, o servidor de assinatura DNSSEC, caracterizado pelo fato de que compreende: um processador; e um dispositivo de armazenamento incluindo código legível por computador que, quando executado pelo processador, faz o servidor de assinatura agir como um servidor autorizado para: receber uma solicitação de assinatura da pelo menos uma aplicação cliente para assinar os primeiros dados; determinar pelo menos uma de uma KSK ativa e uma ZSK ativa para os primeiros dados; transmitir os primeiros dados a uma da pluralidade de módulos de assinatura digital; receber uma versão assinada digitalmente dos primeiros dados do módulo de assinatura digital; e fornecer os primeiros dados assinados para a aplicação cliente.
2. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que o servidor de assinatura é ainda configurado para: receber, como parte da mesma solicitação de assinatura, uma solicitação para assinar segundos dados; determinar pelo menos uma de uma KSK ativa e ZSK ativa para os segundos dados, e que pode ser diferente do que a pelo menos uma KSK ativa e / ou ZSK ativa para os primeiros dados; transmitir os segundos dados a um da pluralidade de módulos de assinatura digital; receber uma versão assinada digitalmente dos segundos dados a partir do módulo de assinatura digital, e fornecer os segundos dados assinados para a aplicação cliente.
3. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que os primeiros dados inclui dados DNS, e os módulos de assinatura digital são configurados para assinar certas partes dos dados DNS de acordo com um protocolo DNSSEC, sem assinar um zona inteira.
4. Servidor, de acordo com a reivindicação 3, caracterizado pelo fato de que o servidor de assinatura é ainda configurado para fornecer uma função de assinatura digital não DNSSEC adicional.
5. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que o servidor de assinatura é ainda configurado para: receber várias solicitações de assinatura como parte de um único pacote de solicitação; e analisar o pacote de solicitação para identificar as solicitações de assinatura diferentes que têm pelo menos uma de KSKs ativas, ZSKs ativas, e protocolos de assinatura diferentes um do outro.
6. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que a pelo menos uma KSK ativa e ZKS ativa são determinadas com base em um identificador TLD incluído na solicitação de assinatura.
7. Servidor, de acordo com a reivindicação 6, caracterizado pelo fato de que o servidor de assinatura é ainda configurado para distinguir uma função de assinatura solicitada entre pluralidade de diferentes funções de assinatura digital com base em um identificador de tipo de serviço incluído na solicitação de assinatura, e para rotear solicitações de assinatura não DNSSEC para um módulo de assinatura digital não DNSSEC com base no identificador de tipo de serviço.
8. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que cada um dos módulos de assinatura digital inclui um Módulo de Segurança de Hardware (HSM), que é fisicamente separado a partir do processador do servidor de assinatura e que é configurado para assinar digitalmente dados fornecidos pelo servidor de assinatura.
9. Servidor, de acordo com a reivindicação 8, caracterizado pelo fato de que o HSM inclui uma pluralidade de chaves identificadas por identificadores de pseudônimos, e o servidor de assinatura é ainda configurado para passar um identificador de pseudônimo para pelo menos uma de uma KSK e uma ZSK para os dados DNS para o módulo de assinatura digital sem passar a pelo menos uma KSK e ZSK para o módulo de assinatura digital.
10. Servidor, de acordo com a reivindicação 9, caracterizado pelo fato de que o servidor de assinatura é ainda configurado para verificar periodicamente um banco de dados de KSKs ou ZSKs ativas e para determinar quais os identificadores de pseudônimos são ativos para um tempo determinado com base em informações recebidas do banco de dados, e em que o identificador de pseudônimo passado para o módulo de assinatura digital é um identificador de pseudônimo ativo.
11. Servidor, de acordo com a reivindicação 9, caracteri zado pelo fato de que o servidor é ainda configurado para identificar um HSM especifico para enviar os primeiros dados para, com base na pelo menos uma KSK ativa e / ou ZSK ativa.
12. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que o servidor de assinatura é ainda configurado para processar solicitações relativas a domínios sob diferentes Domínios de Alto Nivel.
13. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que a assinatura é ainda configurada para processar solicitações relativas a pelo menos dois domínios administrados por uma pluralidade de registradores.
14. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que comunicações entre o cliente e o servidor de assinatura são realizadas através de SSL de duas vias.
15. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que a assinatura é ainda configurada para: determinar mais de uma chave ativa e / ou algoritmo ativo para os primeiros dados; transmitir identificadores para a mais de uma chave ativa e / ou algoritmo ativo para o módulo de assinatura digital; receber uma pluralidade de versões assinadas digitalmente dos primeiros dados do módulo de assinatura digital; e fornecer a pluralidade de versões digitalmente assinadas dos primeiros dados para a aplicação cliente.
16. Servidor, de acordo com a reivindicação 1, caracterizado pelo fato de que o módulo de assinatura digital dinamicamente carrega a pelo menos uma de KSK ativa e ZSK ativa para os primeiros dados a partir de um banco de dados em resposta à recepção dos primeiros dados.
17. Método de criptografar informações DNS por um servidor de assinatura DNSSEC configurado para interagir com pelo menos uma aplicação cliente DNSSEC e uma pluralidade de módulos de assinatura digital, o método caracterizado pelo fato de que compreende: receber uma solicitação de assinatura da pelo menos uma aplicação cliente para assinar primeiros dados; determinar pelo menos uma de uma KSK ativa e uma ZSK ativa para os primeiros dados; transmitir os primeiros dados a uma da pluralidade de módulos de assinatura digital; receber uma versão assinada digitalmente dos primeiros dados a partir do módulo de assinatura digital, e fornecer os primeiros dados assinados para a aplicação cliente.
18. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que compreende ainda: receber, como parte da mesma solicitação de assinatura, uma solicitação para assinar segundos dados; determinar pelo menos uma de uma KSK ativa e uma ZSK ativa para os segundos dados, e que pode ser diferente do que a pelo menos uma KSK ativa e / ou ZSK ativa para os primeiros dados; transmitir os segundos dados para um da pluralidade de módulos de assinatura digital; receber uma versão assinada digitalmente dos segundos dados a partir do módulo de assinatura digital, e fornecer os segundos dados assinados para a aplicação cliente.
19. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que os primeiros dados incluem dados DNS, e os módulos de assinatura digital são configurados para assinar certas partes dos dados DNS de acordo com um protocolo DNSSEC, sem assinar uma zona inteira.
20. Método, de acordo com a reivindicação 19, caracterizado pelo fato de que o servidor de assinatura é ainda configurado para fornecer uma função de assinatura digital não DNSSEC adicional.
21. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que as solicitações de assinatura múltiplas são recebidas como parte de um único pacote de solicitação, o método compreendendo ainda: analisar o pacote de solicitação para identificar as solicitações de assinatura diferentes tendo pelo menos uma de KSKs ativas, ZSKs ativas, e protocolos de assinatura diferentes um do outro.
22. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que a pelo menos uma KSK ativa e ZKS ativa são determinadas com base em um identificador TLD incluído na solicitação de assinatura.
23. Método, de acordo com a reivindicação 22, caracterizado pelo fato de que compreende ainda distinguir uma função de assinatura solicitada de entre pluralidade de diferentes funções de assinatura digital com base em um identificador de tipo de serviço incluído na solicitação de assinatura, e rotear solicitações de assinatura não DNSSEC para um módulo de assinatura digital não DNSSEC baseado no identificador de tipo de serviço.
24. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que cada um dos módulos de assinatura digital inclui um Módulo de Segurança de Hardware (HSM), que é fisicamente separado do processador do servidor de assinatura e que é configurado para assinar digitalmente dados fornecidos pelo servidor de assinatura.
25. Método, de acordo com a reivindicação 24, caracterizado pelo fato de que o HSM inclui uma pluralidade de chaves identificadas por identificadores de pseudônimos o método compreendendo ainda passar um identificador de pseudônimo para pelo menos uma de uma KSK e uma ZSK para os dados DNS para o módulo de assinatura digital sem passar a pelo menos uma KSK e ZSK para o módulo de assinatura digital.
26. Método, de acordo com a reivindicação 25, caracteri zado pelo fato de que compreende ainda verificar periodicamente um banco de dados de KSKs ou ZSKs ativas e determinar quais identificadores de pseudônimos são ativos para um tempo determinado com base em informações recebidas do banco de dados, e em que o identificador de pseudônimo passado para o módulo de assinatura digital é um identificador de pseudônimo ativo.
27. Método, de acordo com a reivindicação 25, caracterizado pelo fato de que compreende ainda identificar um HSM especifico para enviar os primeiros dados para, com base na pelo menos uma KSK ativa e / ou ZSK ativa.
28. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que compreende ainda processar solicitações relativas a domínios sob diferentes Domínios de Alto Nível.
29. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que compreende ainda processar solicitações relativas a pelo menos dois domínios administrados por uma pluralidade de registradores.
30. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que comunicações entre o cliente e o servidor de assinatura são realizadas através de SSL de duas vias.
31. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que compreende ainda: determinar mais de uma chave ativa e / ou algoritmo ativo para os primeiros dados; transmitir identificadores para a mais do que uma chave ativa e / ou algoritmo ativo para o módulo de assinatura digital; receber uma pluralidade de versões assinadas digitalmente dos primeiros dados do módulo de assinatura digital; e fornecer a pluralidade de versões assinadas digitalmente de primeiros dados para a aplicação cliente.
32. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que compreende ainda dinamicamente carregar, no módulo de assinatura digital, a pelo menos uma de KSK ativa e ZKS ativa para os primeiros dados a partir de um banco de dados em resposta à recepção dos primeiros dados
BRBR102012010346-0A 2011-05-02 2012-05-02 Servidor de assinatura de extensão de segurança de sistema de nome de domínio (dnssec) e método de criptografar informações de sistema de nome de domínio (dns) utilizando o mesmo BR102012010346A2 (pt)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/098,940 US9130917B2 (en) 2011-05-02 2011-05-02 DNSSEC signing server

Publications (1)

Publication Number Publication Date
BR102012010346A2 true BR102012010346A2 (pt) 2015-08-11

Family

ID=46061989

Family Applications (1)

Application Number Title Priority Date Filing Date
BRBR102012010346-0A BR102012010346A2 (pt) 2011-05-02 2012-05-02 Servidor de assinatura de extensão de segurança de sistema de nome de domínio (dnssec) e método de criptografar informações de sistema de nome de domínio (dns) utilizando o mesmo

Country Status (7)

Country Link
US (3) US9130917B2 (pt)
EP (1) EP2521330B1 (pt)
JP (1) JP2012235464A (pt)
CN (1) CN102769529B (pt)
AU (1) AU2012202493B2 (pt)
BR (1) BR102012010346A2 (pt)
CA (1) CA2775693C (pt)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9106695B2 (en) * 2012-03-14 2015-08-11 Daniel Kaminsky Method and system for user authentication using DNSSEC
US9215205B1 (en) * 2012-04-20 2015-12-15 Infoblox Inc. Hardware accelerator for a domain name server cache
US10715377B2 (en) * 2012-12-21 2020-07-14 Comcast Cable Communications, Llc Domain name services servers management to share data efficiently
CN104253793A (zh) * 2013-06-27 2014-12-31 政务和公益机构域名注册管理中心 域名系统的安全扩展的密钥签名密钥和区域签名密钥的更新方法
US9380019B2 (en) * 2013-08-26 2016-06-28 Verisign, Inc. Command performance monitoring
US9300623B1 (en) * 2014-02-18 2016-03-29 Sprint Communications Company L.P. Domain name system cache integrity check
CN103746817B (zh) * 2014-02-18 2018-01-09 互联网域名系统北京市工程研究中心有限公司 Dnssec签名方法及其系统
EP3123689B1 (de) * 2014-03-26 2022-05-11 Continental Teves AG & Co. OHG Verfahren und system zur verbesserung der datensicherheit bei einem kommunikationsvorgang
US9544266B2 (en) * 2014-06-27 2017-01-10 Microsoft Technology Licensing, Llc NSEC3 performance in DNSSEC
US9894050B1 (en) * 2014-08-11 2018-02-13 Google Llc Server based settings for client software with asymmetric signing
US9473516B1 (en) * 2014-09-29 2016-10-18 Amazon Technologies, Inc. Detecting network attacks based on a hash
CN104486087B (zh) * 2014-12-23 2017-12-29 中山大学 一种基于远程硬件安全模块的数字签名方法
US9544278B2 (en) 2015-01-07 2017-01-10 Red Hat, Inc. Using domain name system security extensions in a mixed-mode environment
US9762556B2 (en) * 2015-01-09 2017-09-12 Verisign, Inc. Registering, managing, and communicating with IOT devices using domain name system processes
EP3051469B1 (en) 2015-01-28 2024-05-22 Inexto Sa Method and apparatus for unit and container identification and tracking
CN104618116B (zh) * 2015-01-30 2019-03-08 北京数字认证股份有限公司 一种协同数字签名系统及其方法
PL3051372T3 (pl) 2015-01-31 2019-10-31 Inexto Sa Zabezpieczona identyfikacja i weryfikacja produktu
EP3257192B1 (en) * 2015-02-14 2020-08-12 Valimail Inc. Secure and delegated distribution of private keys via domain name service
US10270742B2 (en) * 2015-03-27 2019-04-23 Arris Enterprises Llc Cryptographic service with output redirection
US9954840B2 (en) * 2015-05-08 2018-04-24 Cloudflare, Inc. Generating a negative answer to a domain name system query that indicates resource records as existing for the domain name regardless of whether those resource records actually exist for the domain name
US10033699B2 (en) 2015-05-08 2018-07-24 Cloudflare, Inc. Transparent DNSSEC-signing proxy
US20180205543A1 (en) 2015-08-13 2018-07-19 Inexto Sa Enhanced obfuscation or randomization for secure product identification and verification
CN106470250B (zh) * 2015-08-19 2019-09-10 互联网域名系统北京市工程研究中心有限公司 域名注册方法、装置和系统
EP3342122B1 (en) 2015-08-25 2020-08-19 Inexto Sa Multiple authorization modules for secure production and verification
CN108140076B (zh) 2015-08-25 2022-04-05 英艾克斯图股份有限公司 用于安全产品标识符的具有容错的验证
US10178195B2 (en) * 2015-12-04 2019-01-08 Cloudflare, Inc. Origin server protection notification
US10153905B2 (en) * 2015-12-04 2018-12-11 Verisign, Inc. Hash-based electronic signatures for data sets such as DNSSEC
US11025407B2 (en) 2015-12-04 2021-06-01 Verisign, Inc. Hash-based digital signatures for hierarchical internet public key infrastructure
US10181954B2 (en) * 2016-03-28 2019-01-15 Digicert, Inc. Cloud-based code signing service—hybrid model to avoid large file uploads
US20180024807A1 (en) * 2016-07-21 2018-01-25 Vision Menu, Inc. System and Method of Document and Signature Management
US10367825B2 (en) * 2016-12-28 2019-07-30 Verisign, Inc. Method and system for parallel validation of domain name system security extension records
US11032127B2 (en) 2017-06-26 2021-06-08 Verisign, Inc. Resilient domain name service (DNS) resolution when an authoritative name server is unavailable
US11394540B1 (en) * 2018-08-30 2022-07-19 United Services Automobile Association (Usaa) Multi autonomous secure domain name systems
US11468435B1 (en) * 2019-01-03 2022-10-11 Blockchain Innovation, Llc Apparatus and methods of air-gapped crypto storage using diodes
CN110071810B (zh) * 2019-04-25 2021-10-01 哈尔滨工业大学 一个基于开源dns软件的自证根实现方法
CN111164594B (zh) 2019-07-02 2023-08-25 创新先进技术有限公司 用于将去中心化标识映射到真实实体的系统和方法
WO2019179535A2 (en) 2019-07-02 2019-09-26 Alibaba Group Holding Limited System and method for verifying verifiable claims
WO2019179533A2 (en) 2019-07-02 2019-09-26 Alibaba Group Holding Limited System and method for issuing verifiable claims
WO2019179534A2 (en) 2019-07-02 2019-09-26 Alibaba Group Holding Limited System and method for creating decentralized identifiers
CN111316303B (zh) 2019-07-02 2023-11-10 创新先进技术有限公司 用于基于区块链的交叉实体认证的系统和方法
CN111213147B (zh) 2019-07-02 2023-10-13 创新先进技术有限公司 用于基于区块链的交叉实体认证的系统和方法
US11562349B2 (en) * 2019-08-20 2023-01-24 Anchor Labs, Inc. Risk mitigation for a cryptoasset custodial system using data points from multiple mobile devices
EP4101123A4 (en) * 2020-02-04 2024-01-24 Valimail Inc SPATIAL BROADCAST DEVICE AUTHENTICATION
US11575646B2 (en) * 2020-03-12 2023-02-07 Vmware, Inc. Domain name service (DNS) server cache table validation
US11444931B1 (en) * 2020-06-24 2022-09-13 F5, Inc. Managing name server data
US11233767B1 (en) 2020-07-02 2022-01-25 Afilias Limited System and method for publishing DNS records of a domain including either signed or unsigned records
US11405353B2 (en) 2020-07-16 2022-08-02 Afilias Limited System and method for generating concurrently live and test versions of DNS data
US11218326B1 (en) * 2020-07-02 2022-01-04 Afilias Limited System and method for generating current live and test versions of DNS data for rollover
US11297033B2 (en) 2020-07-02 2022-04-05 Afilias Limited System and method for generating current live and test versions of DNS data for HSM changes
CN114079645B (zh) * 2020-08-13 2022-12-30 花瓣云科技有限公司 注册服务的方法及设备
US11870801B2 (en) * 2021-01-27 2024-01-09 Paypal, Inc. Protecting computer system end-points using activators
CN113296812A (zh) * 2021-06-09 2021-08-24 深圳忆联信息系统有限公司 Windows系统升级的批量签名方法、装置及计算机设备
WO2022271928A1 (en) * 2021-06-23 2022-12-29 Arris Enterprises Llc Distributed signing system

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3617406B2 (ja) * 2000-03-30 2005-02-02 日本電気株式会社 マルチドメインに対応した品質保証型通信サービス提供方式およびサービス提供方法並びにサービス仲介装置
US6845400B2 (en) * 2000-12-28 2005-01-18 Nortel Networks Limited Storing subscriber location indication at DNS, to enable location specific provision of internet content
EP1974522B1 (fr) * 2005-12-27 2012-10-17 France Telecom Serveur, client et procédé pour gérer des requetes DNSSEC
FR2908540A1 (fr) * 2006-11-15 2008-05-16 France Telecom Deploiement de bases dnssec
CN101242426B (zh) * 2007-02-06 2010-12-08 华为技术有限公司 建立传输层安全连接的方法、系统及装置
CN101277257B (zh) * 2007-03-26 2012-02-01 华为技术有限公司 一种dns动态更新的方法、装置和系统
CA2586223A1 (en) * 2007-04-19 2007-07-18 Cannotech Experts-Conseils Inc. Opt-in process and nameserver system for ietf dnssec
WO2009070430A2 (en) * 2007-11-08 2009-06-04 Suridx, Inc. Apparatus and methods for providing scalable, dynamic, individualized credential services using mobile telephones
US8429715B2 (en) * 2008-08-08 2013-04-23 Microsoft Corporation Secure resource name resolution using a cache
WO2010145686A1 (en) * 2009-06-15 2010-12-23 Nokia Siemens Networks Oy Gateway certificate creation and validation
WO2012009430A1 (en) * 2010-07-13 2012-01-19 Verisign, Inc. System and method for zone signing and key management in a dns system
US8347100B1 (en) * 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US8549148B2 (en) * 2010-10-15 2013-10-01 Brocade Communications Systems, Inc. Domain name system security extensions (DNSSEC) for global server load balancing
US8711843B2 (en) * 2010-10-29 2014-04-29 Telefonaktiebolaget Lm Ericsson (Publ) Cryptographically generated addresses using backward key chain for secure route optimization in mobile internet protocol
US8498414B2 (en) * 2010-10-29 2013-07-30 Telefonaktiebolaget L M Ericsson (Publ) Secure route optimization in mobile internet protocol using trusted domain name servers
US8953798B2 (en) * 2010-10-29 2015-02-10 Telefonaktiebolaget L M Ericsson (Publ) Enhanced cryptographically generated addresses for secure route optimization in mobile internet protocol
CN103314566B (zh) * 2010-11-05 2017-05-03 思杰系统有限公司 用于管理域名系统安全（dnssec）的系统和方法

Also Published As

Publication number Publication date
US10158620B2 (en) 2018-12-18
US9130917B2 (en) 2015-09-08
CA2775693A1 (en) 2012-11-02
JP2012235464A (ja) 2012-11-29
US20170324724A1 (en) 2017-11-09
AU2012202493B2 (en) 2016-03-17
US20120284505A1 (en) 2012-11-08
US9749307B2 (en) 2017-08-29
EP2521330B1 (en) 2015-08-12
CN102769529A (zh) 2012-11-07
US20150372822A1 (en) 2015-12-24
EP2521330A1 (en) 2012-11-07
CA2775693C (en) 2019-05-07
CN102769529B (zh) 2017-04-12

Similar Documents

Publication Publication Date Title
US10158620B2 (en) DNSSEC signing server
EP2518970B1 (en) Dnssec inline signing
Afanasyev et al. NDNS: A DNS-like name service for NDN
US11818142B2 (en) Distributed data authentication and validation using blockchain
Ariyapperuma et al. Security vulnerabilities in DNS and DNSSEC
US9258293B1 (en) Safe and secure access to dynamic domain name systems
US9935771B2 (en) Methods and systems for bootstrapping
US11444931B1 (en) Managing name server data
TW202042159A (zh) 與分散式帳本相關聯之目的地定址技術
Rajendran et al. Domain name system (dns) security: Attacks identification and protection methods
Conrad Towards improving DNS security, stability, and resiliency
Neumann et al. DNStamp: Short-lived trusted timestamping
Gorjón et al. Discovery method for a DNSSEC validating stub resolver
KR20120124044A (ko) Ｄｎｓｓｅｃ 서명 서버
JP2012199607A (ja) Ｄｎｓｓｅｃ代理装置
ROSTAMPOUR Deploying DNS Security Extensions
Agar The domain name system (DNS): Security challenges and improvements
de Jong et al. Securing DNS
Cymru Incident Response Guide to the Kaminsky DNS Cache Poison Exploit
KR20120122979A (ko) Ｄｎｓｓｅｃ 인라인 서명
SCHEERDER et al. SHAPING DNS SECURITY WITH CURVES
Weaver et al. RASD–Rapid Adaptive Secure DNS

Legal Events

Date Code Title Description
B03A Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette]
B11A Dismissal acc. art.33 of ipl - examination not requested within 36 months of filing
B11Y Definitive dismissal - extension of time limit for request of examination expired [chapter 11.1.1 patent gazette]