2 Pol

1
2Políticas, Modelos e Mecanismos de Segurança

• O papel do controle de acesso
• Matriz de controle de acesso
• Resultados fundamentais
• Políticas de segurança
• Modelos de segurança
• Mecanismos e implementação

2
Mecanismos e implementação (1)

• Princípios de projeto (1)
• Menor privilégio
• Defaults seguros na falha
• Mecanismo econômico
• Princípio da mediação completa
• Projeto aberto
• Separação de privilégios
• Menor mecanismo possível
• Princípio da aceitação psicológica

3
Mecanismos e implementação (2)

• Princípios de projeto (2)
• Simplicidade
• Reduz as possibilidade de erro
• Reduz o potencial de inconsistências numa
  política ou num conjunto de políticas
• Facilita o entendimento
• Restrições
• Minimizar o acesso como meio de reduzir o poder
  de uma entidade
• Acessar apenas informações necessárias
• Inibir a comunicação desnecessária

4
Mecanismos e implementação (3)

• Princípios de projeto (3)
• Princípio do menor privilégio
• Deve-se conceder a um sujeito somente os
  privilégios necessários para ele executar suas
  tarefas
• Se um sujeito necessita de direitos para anexar
  informações num objeto, mas não alterá-las,
  deveria-se dar direitos de append para ele e não
  direitos para escrita
• As funções do sujeito devem controlar a concessão
  de direitos, não a identidade
• Direitos devem ser concedidos conforme a
  necessidade, sendo descartados imediatamente após
  a finalização da tarefa
• Na prática, a maioria dos sistemas não tem o
  nível de granularidade de privilégios requerido
  para aplicar este princípio precisamente
• Requer o confinamento de processos no menor
  domínio de proteção possível

5
Mecanismos e implementação (4)

• Princípios de projeto (4)
• Princípio do defaults seguros na falha
• A menos que seja concedido acesso explícito de um
  sujeito para um objeto, esse acesso deve ser
  negado para o objeto
• O acesso a um objeto deve ser negado por default
• Por exemplo, na falha de um login, e. g., banco
  fora do ar, deve-se recusar o acesso
• Na leitura de um arquivo de configuração,
  considerar apenas as entradas legais e descartar
  todas as outras, assumindo-se um default seguro
• Caso uma ação falhe, o sistema deve retroceder
  para o estado seguro inicial
• Caso o servidor de e-mail não possa mais criar
  arquivos no diretório de spool, ele deve fechar a
  conexão de rede, reportar o erro e parar. Ele não
  deve tentar armazenar a mensagem noutro local,
  expandindo seus privilégios para tal porque um
  atacante pode usar esta facilidade para
  sobrescrever arquivos ou esgotar os discos num
  ataque dos

6
Mecanismos e implementação (5)

• Princípios de projeto (5)
• Princípio do mecanismo econômico
• Os mecanismos de segurança devem ser os mais
  simples possíveis
• Projetos e implementações simples, menos
  possibilidades existem para erros
• Quando erros ocorrem, eles são mais fáceis de
  serem entendidos e consertados
• Definir todas as interfaces completamente
• Interfaces para outros módulos são suspeitas
• Módulos fazem suposições implícitas sobre e-s e o
  estado corrente do sistema
• Suposições infundadas podem produzir resultados
  inesperados
• O protocolo finger assume que a resposta de um
  servidor é bem formada, logo um atacante que crie
  uma versão do protocolo que gera uma cadeia
  infinita de caracteres pode provocar uma recusa
  de serviço pelo esgotamento arquivos de logs ou
  discos
• A interação com entidades externas, como
  programas, sistemas, pessoas amplificam este
  problema

7
Mecanismos e implementação (6)

• Princípios de projeto (6)
• Princípio da mediação completa
• Requer que todos os acessos a objetos sejam
  efetivamente verificados para assegurar que eles
  são permitidos
• Limita a implementação de caches
• A primeira verificação de autorização de acesso a
  um objeto é realizada
• As verificações subseqüentes para o mesmo objeto
  resgatam do cache o resultado da autorização
  anterior
• Caso os direitos de acesso do usuário sejam
  modificados nesse meio tempo, o mecanismos de
  controle de acesso não perceberá
• Exemplos
• Descritores de arquivos, que incluem as LCAs,
  são cacheados no UNIX
• O DNS mantém um cache com informações de
  mapeamento nome de servidor endereço IP, que
  pode ser adulterado com a associação de um IP
  forjado

8
Mecanismos e implementação (7)

• Princípios de projeto (7)
• Princípio do projeto aberto
• A segurança de um mecanismo não deve depender do
  sigilo sobre o seu projeto ou implementação
• Não significa que o código fonte e projeto devam
  ser públicos
• Sigilo aumenta a segurança, mas a segurança de um
  mecanismo não deveria ser afetada pela descoberta
  de sua implementação ou projeto
• Descobrir uma implementação pode não ser muito
  difícil
• Modo como o sistema funciona
• Engenharia reversa
• Dumpster diving
• Não se aplica ao sigilo de informações que não
  envolvem implementação ou projeto
• Chaves de criptografia
• Senhas

9
Mecanismos e implementação (8)

• Princípios de projeto (8)
• Princípio do projeto aberto
• Exemplo
• CCS (Content Scrambling System) é um algoritmo de
  criptografia que protege filmes em discos de DVD
  contra cópias não autorizadas
• Layout de chaves do DVD
• Ka
• hash(Kd)
• E(Kd, Kpi)
• ...
• E(Kd, Kpi)
• E(Kt, Kd)
• Baseava-se num algoritmo frágil, que, quando
  descoberto em 1999, frustrou as expectativas da
  indústria de filmes

10
Mecanismos e implementação (9)

• Princípios de projeto (9)
• Princípio da separação de privilégio
• Um sistema não deve conceder permissão baseada
  numa única condição
• Equivalente ao princípio da separação de
  responsabilidades
• Para valores maiores que R 1.000,00, uma compra
  deve ser autorizada por duas pessoas
• As duas condições correspondem às autorizações
  dadas por duas pessoas distintas
• Exige um controle de acesso com granularidade
  fina sobre recursos
• Defesa em profundidade
• Castelos medievais
• Exemplo assumir a conta do root no Unix de
  Berkeley
• Conhecer a senha do root
• Ser um usuário com GID 0

11
Mecanismos e implementação (10)

• Princípios de projeto (10)
• Princípio do menor mecanismo comum
• Mecanismos usados para acessar recursos não devem
  ser compartilhados
• Informações podem fluir por canais compartilhados
• Canais ocultos
• Isolamento
• Uso de máquinas virtuais atende a este princípio
• KVM/370 versão incrementada da IBM VM/370
• Sandboxes
• Java virtual machine
• Exemplos
• Percentual de CPU utilizados, de discos, etc
• Criação de arquivos com nomes fixos

12
Mecanismos e implementação (11)

• Princípios de projeto (11)
• Princípio da aceitação psicológica
• Um mecanismo de segurança não deve tornar o
  acesso a um recurso mais difícil do que aquele
  obtido sem o mecanismo
• Deve-se ocultar a complexidade introduzida pelos
  mecanismos de segurança
• Facilidade instalação, configuração e uso
• Fatores humanos são críticos

13
Mecanismos e implementação (12)

• Princípios de projeto (12)
• Conclusão
• Os princípios para projetos são a base para todos
  os mecanismos relativos a segurança
• Requer
• Bom entendimento do objetivo do mecanismo e do
  ambiente onde será usado
• Análise e projeto cuidadoso
• Implementação cuidadosa

14
Mecanismos e implementação (13)

• Mecanismos de controle de acesso (1)
• Lista de controle de acesso (LCA)
• Capabilities
• Chave e cadeado
• Segredo compartilhado
• Controle de acesso baseado em anel
• Lista de controle de acesso propagada

15
Mecanismos e implementação (14)

• Mecanismos de controle de acesso (2)
• Lista de controle de acesso (1)
• Cada objeto protegido tem um conjunto de pares
  associado
• Cada par contém um sujeito e um conjunto de
  direitos de acesso
• O sujeito só pode acessar o objeto de acordo com
  esses direitos

16
Mecanismos e implementação (15)

• Mecanismos de controle de acesso (3)
• Lista de controle de acesso (2)
• Exemplo colunas da matriz de controle de acesso
• arquivo1 arquivo2 arquivo3
• André rx r rwo
• Bia rwxo r
• Carlos rx rwo w
• LCAs
• arquivo1 (André, rx) (Bia, rwxo) (Carlos, rx)
  
• arquivo2 (André, r) (Bia, r) (Carlos, rwo)
• arquivo3 (André, rwo) (Carlos, w)

17
Mecanismos e implementação (16)

• Mecanismos de controle de acesso (4)
• Lista de controle de acesso (3)
• Permissões default
• Normal se não for explicitada, não tem direitos
  sobre o objeto
• Princípio do default seguro na falha
• Quando há muitos usuários, pode-se usar grupos ou
  casamento de padrões para conceder permissões
  default
• Exemplo UNICOS LCA formadas por (user, group,
  rights)
• Caso user pertença a group, ele possui os
  direitos rights sobre o objeto protegido
• é o padrão para qualquer user, group
• (Ana, , r) Ana pode ler o objeto, qualquer
  que seja o seu grupo
• (, caixa, w) qualquer membro do grupo caixa
  pode escrever no objeto

18
Mecanismos e implementação (17)

• Mecanismos de controle de acesso (5)
• Lista de controle de acesso (4)
• Abreviações
• LCAs podem ser longas logo, os usuários podem
  ser combinados para reduzi-las
• Unix 3 classes de usuários proprietário, grupo
  do proprietário, os outros usuários
• rwx rwx rwx
• outros
• grupo
• proprietário
• A propriedade é atribuída com base no processo
  criador
• Alguns sistemas se um diretório tem permissão
  setgid, o grupo do arquivo lá criado é herdado do
  grupo do diretório (SunOS, Solaris)

19
Mecanismos e implementação (18)

• Mecanismos de controle de acesso (6)
• Lista de controle de acesso (5)
• Abreviações LCAs
• Abreviações como a do Unix carecem de uma
  granularidade fina
• Qualquer um, menos fulano
• Ana que conceder o direito de leitura para Joana,
  de escrita para Carolina, de leitura e escrita
  para Dúnia e de execução para Elisa
• Isto não pode ser feito apenas com três classes
  de permissão
• Estender listas abreviadas com LCAs
• O objetivo é encurtar as LCAs
• LCAs sobrepõem as abreviações
• A forma exata varia
• Exemplo IBM AIX
• As permissões básicas são abreviações, as
  permissões estendidas são LCAs com usuário, grupo
• LCAs podem adicionar direitos, mas quando
  proibir, o acesso está proibido

20
Mecanismos e implementação (19)

• Mecanismos de controle de acesso (7)
• Lista de controle de acesso (6)
• Abreviações LCAs exemplo no IBM AIX
• attributes
• base permissions
• owner(bishop) rw-
• group(sys) r--
• others ---
• extended permissions enabled
• specify rw- uholly
• permit -w- uheidi, gsys
• permit rw- umatt
• deny -w- uholly, gfaculty

21
Mecanismos e implementação (20)

• Mecanismos de controle de acesso (8)
• Lista de controle de acesso (7)
• Modificações das LCAs
• Quem pode fazer isto?
• Concede-se o direito own para o criador, que
  permite alterar a lista
• O sistema R prover um modificador grant
  (semelhante ao copy flag) que permite que um
  direito seja transferido, de modo que o direito
  de propriedade não é necessário
• A transferência de direitos para outros
  modifica a LCA
• As LCAs se aplicam aos usuários privilegiados
  (root ou administradores)?
• Solaris listas abreviadas não, mas ACLs sim
• Outros produtos varia

22
Mecanismos e implementação (21)

• Mecanismos de controle de acesso (9)
• Lista de controle de acesso (8)
• Modificações das LCAs
• As LCAs suportam grupos e casamento de padrão?

• Na forma clássica não na prática, quase sempre
• AIX as permissões base concederam apenas direito
  de leitura para o grupo sys. A linha
• permit -w- uheidi, gsys
• adiciona direito de escrita para heidi quando
  neste neste grupo
• UNICOS
• ana caixa r
• Usuário ana no grupo caixa pode ler o arquivo
• ana r
• Usuário ana em qualquer grupo pode ler o arquivo
• caixa r
• Qualquer usuário no grupo caixa pode ler o arquivo

23
Mecanismos e implementação (22)

• Mecanismos de controle de acesso (10)
• Lista de controle de acesso (9)
• Modificações das LCAs
• Como são resolvidas as permissões contraditórias
  - conflitos?

• Proibir o acesso se alguma permissão proíbe o
  acesso
• AIX se alguma permissão proíbe o acesso,
  independente dos direitos já concedidos, o acesso
  é negado
• Permitir o acesso se alguma permissão concede o
  acesso
• Aplicar a primeira permissão encontrada
• Roteadores Cisco aplica a primeira entrada da
  LCA que case com o pacote de entrada. Caso
  nenhuma se aplique, o pacote é rejeitado
• Note que por default é negado, seguindo o
  princípio do default seguro na falha

24
Mecanismos e implementação (23)

• Mecanismos de controle de acesso (11)
• Lista de controle de acesso (10)
• Modificações das LCAs
• Quando há permissões default, elas são
  modificadas pelas LCAs ou são usadas apenas
  quando a LCA não menciona um sujeito
  explicitamente?

• Aplica entrada da LCA, caso não seja possível,
  aplica o default
• Roteador Cisco aplica a regra da controle de
  acesso da ACL, caso não exista, usa a regra
  default (proibir o acesso)
• Defaults estendidos por ACLs
• AIX permissões estendidas aumentam as permissões
  base

25
Mecanismos e implementação (24)

• Mecanismos de controle de acesso (12)
• Lista de controle de acesso (11)
• Revogação de direitos - Questão
• Como se removem os direitos de um sujeito sobre
  um arquivo?
• O proprietário remove as entradas relativas ao
  sujeito da LCA, ou apenas direitos específicos,
  conforme o caso
• O que fazer quando não há proprietário?
• Depende do sistema
• Sistema R restaura para o estado de proteção
  anterior a concessão do direito
• Pode significar remover os direitos concedidos
  em cascata

26
Mecanismos e implementação (25)

• Mecanismos de controle de acesso (13)
• Lista de controle de acesso (12)
• Exemplo LCA do Windows NT
• Conjuntos de direitos de acesso diferentes
• Básicos leitura, escrita, execução, exclusão,
  modificar permissão, tomar a propriedade
• Genérico nenhum acesso, leitura
  (leitura/execução), modificação
  (leitura/escrita/execução/exclusão), controle
  total (todos), acesso especial (poder para
  atribuir qualquer direito básico)
• Diretório nenhum acesso, leitura
  (leitura/execução de arquivos no diretório),
  listar, adição, adição e leitura, modificação
  (criação, adição, leitura, execução e escrita de
  arquivos exclusão de subdiretórios), controle
  total, direitos especiais

27
Mecanismos e implementação (26)

• Mecanismos de controle de acesso (14)
• Lista de controle de acesso (13)
• Exemplo LCA do Windows NT
• Acesso a arquivos
• Caso o usuário não esteja em nenhuma LCA nem seja
  membro de grupo presente na LCA acesso proibido
• Alguma entrada da LCA proíbe explicitamente o
  acesso acesso proibido
• Faça a união de todos os direitos que concedem o
  acesso para o usuário o usuário tem este
  conjunto de direitos sobre o arquivo

28
Mecanismos e implementação (27)

• Mecanismos de controle de acesso (15)
• Capabilities (1)
• Cada sujeito tem um conjunto de pares associado
• Cada par contém um objeto protegido e um conjunto
  de direitos de acesso
• O sujeito só pode acessar o objeto de acordo com
  esses direitos

29
Mecanismos e implementação (28)

• Mecanismos de controle de acesso (16)
• Capabilities lista-C (2)
• Exemplo linhas da matriz de controle de acesso
• arquivo1 arquivo2 arquivo3
• André rx r rwo
• Bia rwxo r
• Carlos rx rwo w
• LCAs
• André (arquivo1, rx) (arquivo2, r) (arquivo3,
  rwo)
• Bia (arquivo1, rwxo) (arquivo2, r)
• Carlos (arquivo1, rx) (arquivo2, rwo)
  (arquivo3, w)

30
Mecanismos e implementação (29)

• Mecanismos de controle de acesso (17)
• Capabilities lista-C (3)
• Semântica
• Semelhante a um bilhete aéreo
• A simples posse indica os direitos que o sujeito
  tem sobre o objeto
• O objeto é identificado pela capability
• O nome do objeto deve ser capaz de
  identificá-lo unicamente referência,
  localização, etc.
• Deve-se prevenir que processos possam forjar
  capabilities
• Do contrário, um usuário poderia modificar os
  direitos codificados na capability ou no objeto a
  que se refere

31
Mecanismos e implementação (30)

• Mecanismos de controle de acesso (18)
• Capabilities lista-C (4)
• Implementação
• Arquitetura rotulada
• Bits protegem palavras individuais na memória
• Bit setado processo pode ler, mas não pode
  modificar a memória (palavra)
• Proteções baseadas em páginas ou segmentos
• Colocam-se as capabilities em páginas (segmentos)
  que o processo pode ler, mas não modificar
• O acesso é feito indiretamente via apontadores
• De outro modo, ele poderia usar uma cópia da
  capability, que poderia ser adulterada

32
Mecanismos e implementação (31)

• Mecanismos de controle de acesso (20)
• Capabilities lista-C (6)
• Implementação
• Criptografia
• Associa a cada capability um código verificador
  criptografado com uma chave conhecida do SO
• Quando o processo apresenta a capability, o SO
  valida o código verificador
• Exemplo Amœba, um sistema distribuído baseado em
  capabilities
• Uma capability tem a forma (nome,
  servidor_criador, direitos, código-verificador) e
  é concedido ao proprietário de um objeto
• código-verificador é um número randômico de
  48-bits também armazenado na tabela
  correspondente ao servidor_criador
• Para validação, o sistema compara o
  código-verificador da capability com aquele
  armazenado na tabela servidor_criador
• Um atacante precisa saber o número randômico para
  adulterar a capability, logo, o sistema é
  vulnerável à descoberta da capability

33
Mecanismos e implementação (32)

• Mecanismos de controle de acesso (21)
• Capabilities lista-C (7)
• Cópia de capabilities
• Implica na capacidade de conceder direitos
• Usa-se um copy flag para prevenir um processo de
  distribuir capabilities de forma indiscriminada
• Um processo não pode copiar uma capability para
  outro processo, a menos que o copy flag esteja
  presente
• O copy flag pode ser desligado a critério do
  processo ou do núcleo

34
Mecanismos e implementação (33)

• Mecanismos de controle de acesso (22)
• Capabilities lista-C (8)
• Amplificação de capabilities
• Permite o aumento temporário de privilégios
• Necessário na programação modular com tipos
  abstratos de dados
• O módulo tem operações para empilhar e
  desempilhar dados na pilha
• module stack ... endmodule.
• Uma variável x é declarada com o tipo stack
• var x stack
• Apenas o módulo stack pode alterar ou ler x
• O processo não possui esta capability, mas
  necessita dela quando referencia x
• Solução conceder ao processo as capabilities
  enquanto ele está executando operações no módulo

35
Mecanismos e implementação (34)

• Mecanismos de controle de acesso (23)
• Capabilities lista-C (9)
• Revogação de capabilities
• Requer a varredura de todas as listas-C para
  remover as capabilities relativas a um objeto
• Custo elevado
• Alternativa uso da indireção
• Cada objeto possui uma entrada numa tabela global
  de objetos
• Nomes nas capabilities indicam a entrada na
  tabela, não o objeto real
• - Para revogar, remove-se a entrada na tabela
• - Pode-se ter múltiplas entradas para um mesmo
  objeto para permitir o controle de diferentes
  conjuntos de direitos e/ou grupos de usuários
  para cada objeto
• Exemple Amoeba o proprietário pode requerer a
  mudança do número randômico na tabela
• - Todas as capabilities para o objeto passam a
  ser inválidas

36
Mecanismos e implementação (35)

• Mecanismos de controle de acesso (24)
• Capabilities lista-C (10)
• Limites

• Problemas podem ocorrer caso não se possa
  controlar a cópia de capabilities

A capability para escrever no arquivo lough é
Low, e Heidi é High, ela pode ler (cópias) a
capability portanto, ela pode escrever num
arquivo Low, violando a propriedade-!
37
Mecanismos e implementação (36)

• Mecanismos de controle de acesso (25)
• Capabilities listas de controle de acesso
• Ambas são teoricamente equivalentes
• Dado um sujeito, quais objetos ele pode acessar e
  com quais direitos?
• Dado um objeto, quais sujeitos pode acessá-lo e
  com quais direitos?
• Anteriormente, havia maior interesse em responder
  a segunda questão, razão pela qual os sistemas
  baseados em LCAs se tornaram mais comum que
  aqueles baseados em capabilities
• Isto pode mudar à medida que a primeira questão
  torne-se mais importante

• Capabilities respondem com facilidade

• LCAs respondem com facilidade

38
Mecanismos e implementação (37)

• Mecanismos de controle de acesso (26)
• Chave e cadeado (1)
• Combina características LCAs e de capabilities
• Associa uma informação (cadeado) com um objeto e
  outra informação (chave) com um sujeito
• A chave controla o que o sujeito pode acessar e
  como
• O sujeito apresenta a chave caso ela corresponda
  a algum cadeado do objeto, o acesso é concedido
• Isto pode ser dinâmico
• LCAs e C-Lists em geral são estáticas, devendo
  ser atualizadas manualmente
• Chaves e cadeados podem mudar baseadas em
  restrições no sistema ou em outros fatores

39
Mecanismos e implementação (38)

• Mecanismos de controle de acesso (27)
• Chave e cadeado (2)
• Implementação criptográfica
• A chave de criptografar é o cadeado
• A chave de decriptografar é a chave
• Criptografa o objeto o armazena Ek(o)
• Usa-se a chave k? do usuários para computar
  Dk?(Ek(o))
• Qualquer um de n sujeitos pode acessar o
  armazena-se
• o? (E1(o), , En(o)) or-access
• Requer o consentimento de n sujeitos para acessar
  o armazena-se
• o? (E1(E2((En(o)))) and-accesss

40
Mecanismos e implementação (39)

• Mecanismos de controle de acesso (29)
• Chave e cadeado (3)
• Exemplo IBM 370
• Processos recebem uma chave de acesso e páginas
  têm uma chave de memória e um bit de fetch
• Bit de fetch zerado acesso apenas de leitura
• Bit de fetch 1, chave de acesso 0 o processo
  pode escrever na página (qualquer uma)
• Bit de fetch 1, chave de acesso casa com a chave
  de memória o processo pode escrever na página
• Bit de fetch 1, chave de acesso diferente de zero
  e não casa com a chave de memória nenhum acesso
  é permitido

41
Mecanismos e implementação (40)

• Mecanismos de controle de acesso (30)
• Chave e cadeado (4)
• Exemplo roteador Cisco
• Listas de controle de acesso dinâmicas
• access-list 100 permit tcp any host 10.1.1.1 eq
  telnet
• access-list 100 dynamic test timeout 180 permit
  ip any host \
• 10.1.2.3 time-range my-time
• time-range my-time
• periodic weekdays 900 to 1700
• line vty 0 2
• login local
• autocommand access-enable host timeout 10
• Limita o acesso para 10.1.2.3 no intervalo
  9AM5PM
• Adiciona uma entrada temporária para a conexão
  para o servidor, uma vez que o usuário tenha
  fornecido nome e senha válidos para o roteador
• Conexões válidas por 180 minutos
• - Excluída da LCA depois deste prazo

42
Mecanismos e implementação (41)

• Mecanismos de controle de acesso (31)
• Chave e cadeado (5)
• Verificação de tipos
• Exemplo a chamada de sistema para escrita no
  Unix não funciona para o objeto diretório, mas
  funciona para os que são arquivos
• Exemplo separação dos espaços de Instruções
  Dados do PDP-11
• Exemplo reação contra ataques de overflow na
  pilha pela colocação da pilha em
  segmentos/páginas do tipo não executável
• Deste modo, códigos carregados ilicitamente não
  podem ser executados
• Embora não impeça outras formas desse tipo de
  ataque

43
Mecanismos e implementação (42)

• Mecanismos de controle de acesso (32)
• Chave e cadeado (6)
• Compartilhamento de segredos
• Implementa a separação de privilégios
• Usa um esquema baseado num limiar (t, n)
• Os dados que se pretende acessar é dividido em n
  partes
• Quaisquer t partes são suficientes para derivar o
  dado original
• Or-access combinado com o and-access podem
  realizar esta tarefa
• Para um limiar (3, 10), supondo que cada uma das
  10 pessoas têm uma chave de criptografia própria,
  faz-se a combinação (or-access) 3 a 3 de cada um
  deles, e usa-se a chave de cada pessoa numa
  combinação para criptografar a informação numa
  forma and-access
• Aumenta o número de representações do dados
  rapidamente, à medida que n e t crescem
• Esquemas criptográficos são mais comuns

44
Mecanismos e implementação (43)

• Mecanismos de controle de acesso (33)
• Chave e cadeado (7)
• Compartilhamento de segredos
• Esquema de Shamir usa um limiar (t, n) para
  compartilhar uma chave criptográfica
• Baseado nos polinômios de Lagrange
• Idéia considera-se o polinômio p(x) de grau t
  1, definindo-se o termo p(0) para ser a chave
• Computa-se o valor de p em n pontos, excluíndo-se
  x 0, para distribuir com as n pessoas
• Pela regras da álgebra, são necessários valores
  de p em quaisquer t pontos distintos para derivar
  o polinomial e, conseqüentemente, o termo
  constante a chave