E aí povo, boa noite!
Dando continuidade à tradução de “Scarce Objects”, que começamos no último versículo.
Controle de Uso x Controle de Acesso
A arquitetura de objetos escassos sugerida aqui compartilha de algumas coisas em comum com as capabilidades, mas protege mais tipos de recursos e é muito mais acessível para usuários e programadores. As capabilidades (juntamente com as ACLs) são um meio de implementar o controle de acesso. O controle de acesso simplesmente lida com o primeiro nível de questão, se uma entidade tem acesso ou não a um determinado recurso. Se uma entidade tiver esse acesso, esse acesso será, conforme modelado ou implementado por recursos básicos ou ACLs, de alcance efetivamente ilimitado. Objetos escassos, por outro lado, limitam o uso de recursos de três maneiras – primeiro, limitando a quantidade de recursos usados por invocação, segundo, limitando o número de recursos usados por direito (por ticket) e terceiro, limitando o número de tickets emitidos.
Objetos Escassos e POLA
Um sistema bruto de recursos distribuídos (isto é, o que Mark Miller chama de “caps-as-data”, para distinguir dos recursos locais do TCB (“objeto caps”) que possuem propriedades de segurança estritamente mais fortes) fornece recursos de duração infinita e invocações ilimitadas, não pode ser considerado um verdadeiro sistema de princípio de menor autoridade (POLA, na sigla em inglês). Para que uma referência a objeto implemente POLA, ela deve ser finita em todas as dimensões. Um verdadeiro sistema POLA nunca fornece mais autoridade do que o necessário e adequado para calcular a função necessária. Nunca é necessário ou adequado alocar recursos infinitos e, geralmente, não é necessário alocar recursos grandes. A arquitetura de objetos escassos é o primeiro design para os sistemas de objetos atingirem autoridade finita e permitir pequenas alocações para objetos que precisam apenas de pequenas quantidades de recursos. Objetos escassos são, portanto, a primeira arquitetura a tornar possível o verdadeiro POLA.
Arquitetura de Objetos Escassos
A arquitetura de objetos escassos depende de uma arquitetura de objetos distribuídos que faça suposições mínimas de segurança. Uma boa estratégia de implementação pode ser, portanto, implementar esse modelo em cima de E. Nenhum uso sofisticado de sua arquitetura de capacidade de distribuição precisa ser feito para distribuir com segurança objetos escassos; em vez disso, as características de conservação de recursos de objetos escassos podem ser utilizados para assegurar recursos.
Um portador de direito de invocar um método de objeto escasso assume a forma de um certificado de portador, ou ticket. Pode ser genérico, significando o direito a N invocações a um de um conjunto de objetos semelhantes ou idênticos, ou específico, significando o direito de invocar um método de objeto específico de uma maneira única. Os direitos genéricos são fungíveis e podem ser transferidos de maneira que não possam ser ligados uns aos outros [unlinkably], usando o cegamento de Chaum.
As etapas gerais para construir um objeto escasso são (1) definir um objeto normal e (2) envolvê-lo em uma camada que protege seus métodos públicos usando tickets. Nosso esboço da arquitetura aqui descreve como essa camada de empacotamento pode funcionar.
A camada de empacotamento envolve três servidores diferentes: um agente de transferência (TA, na sigla em inglês), um Provedor, e um Emissor. O Emissor e o TA operam como uma casa da moeda [mint] de dinheiro digital sem contas. O Emissor assina os Tickets. O TA compensa as transferências de tickets para direitos genéricos. Tanto o Emissor quanto o TA têm cópias das chaves privadas (“placas”) correspondentes a cada emissão de direito genérico. Um tipo particular de direito genérico (por exemplo, uma denominação particular de moeda digital) pode ter múltiplas emissões, usualmente ordenados sequencialmente. Dinheiro digital é um caso especial: dinheiro é o mais genérico dos direitos. Aqui está um outro exemplo de um direito genérico, ou classe de objetos fungíveis: “Um banco de dados SQL passível de consulta com até 10 MB de armazenamento e determinado garantias de tempo de resposta padrão”.
É uma opção de design combinar o Emissor e o TA em um único servidor (reduzir a exposição da chave privada) ou mantê-los separados (habilitando assim certos controles pessoais com base na separação de tarefas). Servidores distribuídos, descritos abaixo, são uma maneira ainda melhor de aumentar a confiabilidade dos Emissores e ATs.
Esta foi a segunda parte da obra, no versículo seguinte a terceira.
