Ipfs: Permissões

Em uma investigação mais aprofundada, acho que a única coisa que está faltando é a propriedade de um blob (possivelmente nenhum) e permissões de leitura com base em uma lista (ou várias) controladas pelo proprietário (se não nenhuma). Isso pode ser construído em cima do IPFS sem modificar o fs subjacente.

Seria melhor usar recursos em vez disso. Exemplo ingênuo: criptografe o arquivo com algum segredo e compartilhe o segredo com as pessoas que têm "permissão de leitura".

Exatamente. Cápsulas. Veja e-rights e Tahoe-LAFS

—
Enviado da caixa de correio

Em sexta-feira, 4 de setembro de 2015 às 16h46, Mourad De Clerck [email protected]
escreveu:

Você seria melhor usar recursos em vez disso. Exemplo ingênuo: criptografe o arquivo com algum segredo e compartilhe o segredo com as pessoas que têm "permissão de leitura".

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ipfs/ipfs/issues/86#issuecomment -137755902

Criptografia para gerenciar permissões é uma péssima ideia. Funciona bem em cenários otimistas, mas não se sustenta muito bem na realidade.

Por exemplo, supondo que um arquivo criptografado seja distribuído em vários nós e alcance alguém com intenções maliciosas, eles podem se esforçar para descriptografar o arquivo. Em um mundo otimista, eles falham e todos ficam felizes. Isso!

No mundo real, se o arquivo foi criado há algum tempo, é possível que uma falha no algoritmo de criptografia tenha sido encontrada desde então. Ou é possível que um novo hardware especial de descriptografia se torne amplamente disponível. Isso reduziria drasticamente a complexidade do processo de descriptografia. Como ninguém realmente possui o arquivo, não há como extrair o arquivo existente e substituí-lo por uma nova versão criptografada com um algoritmo novo e mais seguro. Mesmo se você pudesse fazer algo assim, o que lhe diz que o nó malicioso não manterá a versão anterior do arquivo de qualquer maneira.

No final das contas, nada melhor do que impedir que o arquivo saia da rede quando o assunto é segurança e privacidade.

Em vez de permissões de arquivo, acho que seria mais significativo fazê-lo em um nível de nó. Basicamente, um nó deve ser capaz de recusar conexões de outros nós com base em um paradigma de lista branca/lista negra. Isso permitiria que as pessoas criassem uma rede IPFS privada, um pouco como rastreadores de torrent de bits privados, para compartilhar dados confidenciais, evitando vazamentos para um nó malicioso.

Talvez pudéssemos até considerar uma lista negra de nós globalmente distribuída, armazenada no próprio IPFS, para bloquear automaticamente nós maliciosos conhecidos. No entanto, não sei o quão útil isso seria, considerando que uma identidade de nó pode ser simplesmente regenerada por meio de um novo par de chaves.

Também concordo que a criptografia é a maneira mais direta de fazer isso.
Esquemas de criptografia podem ser hackeados, mas os nós também podem. Os usuários simplesmente precisam
estar ciente dessas potencialidades ao tentar fornecer controle de acesso
para bolhas.
Em 9 de setembro de 2015 18:48, "Etienne Maheu" [email protected] escreveu:

Criptografia para gerenciar permissões é uma péssima ideia. Funciona bem em
cenários otimistas, mas não se sustenta muito bem na realidade.

Por exemplo, supondo que um arquivo criptografado seja distribuído entre
vários nós e alcançar alguém com intenções maliciosas, então eles podem
colocar algum esforço para descriptografar o arquivo. Em um mundo otimista, eles
falhar, e todos estão felizes. Isso!

No mundo real, se o arquivo foi criado há algum tempo, é
possível que uma falha no algoritmo de criptografia tenha sido encontrada desde então.
Ou é possível que o novo hardware especial de descriptografia se torne amplamente
acessível. Isso reduziria drasticamente a complexidade da descriptografia
processo. Como ninguém realmente possui o arquivo, não há como puxar o arquivo
arquivo existente e substitua-o por uma nova versão criptografada com um
algoritmo novo e mais seguro. Mesmo se você pudesse fazer algo assim, o que
informa que o nó malicioso não manterá a versão anterior do arquivo
de qualquer forma.

No final, nada melhor do que impedir que o arquivo saia da rede
quando se trata de segurança e privacidade.

Em vez de permissões de arquivo, acho que seria mais significativo fazê-lo
em um nível de nó. Basicamente, um nó deve ser capaz de recusar conexões
de outros nós com base em um paradigma de lista branca/lista negra. Isso deixaria
as pessoas criam uma rede IPFS privada, um pouco como torrent privado
rastreadores, para compartilhar dados confidenciais, evitando vazamentos para um
nó.

Talvez possamos até considerar uma lista negra de nós distribuídos globalmente,
armazenados no próprio IPFS, para bloquear automaticamente nós maliciosos conhecidos.
No entanto, não sei o quão útil isso seria considerar uma identidade de nó
pode ser simplesmente regenerado por meio de um novo par de chaves.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/ipfs/ipfs/issues/86#issuecomment -138988589.

@ekg A diferença é que, se houver uma falha na segurança de um nó ou no próprio sistema de lista de permissões, ele poderá ser atualizado porque "você está no controle" de todos os nós afetados em sua rede. Se você optar por confiar em um nó, cabe a você garantir que ele seja seguro. Se uma falha aparecer, isso não significa que você vazou dados, apenas que você deve corrigi-la o mais rápido possível. Você não pode fazer isso quando se trata de criptografia em um sistema de arquivos distribuído. Se um arquivo usa criptografia quebrada, você não tem essa segunda chance.

@kawazoe , leia os modelos de capacidade . cada esquema de permissão individual pode ser representado em um sistema de capacidade, portanto, é um sistema _estritamente superior_. os papéis são abundantes.

um nó deve ser capaz de recusar conexões de outros nós com base em um paradigma de lista branca/lista negra. Isso permitiria que as pessoas criassem uma rede IPFS privada, um pouco como rastreadores de torrent de bits privados, para compartilhar dados confidenciais, evitando vazamentos para um nó malicioso.

isso já está planejado, mas ortogonal.

@jbenet Não estou dizendo que os recursos são ruins. É ótimo que você planeja usar este modelo. O que estou dizendo é que há uma diferença distinta entre um recurso de acesso e um recurso de leitura (não importa em que nível ou como ele é implementado) e que criptografar os dados por si só não é suficiente para distinguir os dois.

Ter um nó que controla quais nós têm permissão para recuperar um determinado arquivo deve ser uma coisa. Criptografar os arquivos não é bom em alguns cenários. Algum exemplo:
Ter algum serviço de mídia, onde as pessoas têm que pagar para acessar o conteúdo. Para economizar largura de banda, usar o IPFS faria sentido, se eles pudessem garantir que apenas aqueles que pagassem pudessem acessar os arquivos, pelo menos por meio de seus nós e dos nós dos usuários honestos. Se os arquivos fossem protegidos apenas por criptografia, seria necessário apenas um único usuário que extraísse a chave por meio, e os piratas poderiam roubar o conteúdo por meio do IPFS. Sem criptografia assíncrona, você nem saberia quais usuários distribuíram a chave e, com criptografia assíncrona, você não obtém as vantagens do IPFS. Por favor, reconsidere isso.

Uma maneira de implementar isso seria que o nó que é solicitado pelo arquivo solicitasse alguma autoridade, se o nó tentando acessar o arquivo tinha permissão para fazê-lo, e agiria com base nisso. Também não deve ser muito difícil fazer isso, e definitivamente haveria usuários.

@jcgruenhage Você pode fazer com que todos os usuários da rede estejam na mesma rede privada. (consulte https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-284341649 para obter mais informações sobre redes privadas)

Além disso, você poderia implementar isso como uma extensão de bitswap especial, mas então você se depara com alguns problemas estranhos, tentando ter conteúdo 'privado' não criptografado enquanto ainda está conectado à rede primária. E se alguém fora do 'grupo permitido' obtiver o arquivo por outros meios (e ele tiver o mesmo hash) e, em seguida, um nó no grupo permitido o pegar (talvez seja parte de algum outro arquivo baixado). Eles devem então servir os arquivos para outros peers que os solicitaram, uma vez que vieram de uma fonte não protegida?

O recurso de rede privada parece interessante, mas forçaria as pessoas a ter um nó completamente separado para acessar esse conteúdo, e duvido que seja isso que a maioria das pessoas desejaria. Além disso, temos novamente uma única chave que precisaria ser comprometida, em vez de uma autoridade central que tem controle sobre quem obtém o arquivo.

Sobre se um nó deve compartilhar o arquivo se o obtiver de outro lugar, como eles devem saber que o arquivo tem acesso restrito? Acho que compartilhá-lo está bom, porque o que estou tentando garantir é apenas que, se alguém "roubar" o arquivo, os nós do servidor que fixaram os arquivos e os nós dos usuários honestos não façam seus downloads super rápido, porque eles podem baixá-lo de todos esses nós também, mas apenas daqueles usuários não tão honestos.

@jcgruenhage Concordo com a inconveniência de exigir uma rede privada.

Além disso, não está claro o quanto a rede privada ajuda porque, ao descriptografar os dados, um usuário desonesto pode enviar imediatamente esses dados para a rede pública. Por favor, corrija-me se algo impede isso.

Se a rede privada tivesse no máximo dois nós, o nó honesto saberia que o outro nó está vazando dados de forma desonesta. Permita mais de dois nós na rede privada e o determinismo de vazamento é perdido.

Mesmo na rede privada de dois nós, o nó honesto não saberia imediatamente que os dados estão vazando. O tempo passaria e, nesse ponto, os dados poderiam estar na metade da galáxia.

Uma solução possível é adicionar um ID de nó criptografado / ID de rastreador durante a descriptografia do arquivo. Assim, cada usuário obtém uma cópia ligeiramente modificada de cada arquivo contendo um identificador de rastreador/nó exclusivo para eles. Os arquivos descriptografados sempre seriam diferentes do original, mas o original permaneceria imutável e verificável.

Os nós sentinela relacionados à rede privada podem monitorar a rede pública para esses valores de rastreador. Dessa forma, seria possível detectar a origem do vazamento em tempo hábil.

Isso não impediria que um nó em uma rede privada vazasse dados para outra rede privada.

Você não pode impedir que os usuários compartilhem os arquivos, mas deve ser capaz de impedi-los de usar sua infraestrutura para isso, mas atualmente não há nenhum sistema de distribuição de arquivos distribuído que faça isso ainda.

@jcgruenhage hrm ... Esse é um caso de uso interessante. Será que cada participante
node pergunta ao servidor sobre cada bloco que está sendo solicitado? Ou a autenticação
servidor envia uma grande lista de peers permitidos e qual conteúdo eles são
permitido usar?

Em sex, 2 de junho de 2017, 09:19 de janeiro Christian Grünhage [email protected]
escreveu:

Você não pode impedir que os usuários compartilhem os arquivos, mas deve ser capaz de
impedi-los de usar sua infraestrutura para isso, mas atualmente não há
sistema de distribuição de arquivos distribuído que ainda faz isso.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ipfs/ipfs/issues/86#issuecomment-305836646 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ABL4HGtd8flt7agdikQeIrSk59vnTZzvks5sADYlgaJpZM4F3vN7
.

O recurso de Redes Privadas foi construído com base em um conceito de total confiança de seus pares PNet.

O próximo passo pode ser o sistema de recursos, onde você pode permitir que alguns nós acessem alguns arquivos. O ator malicioso nesse esquema seria capaz de vazar apenas os dados para os quais ele tem capacidade, já que outros nós que têm capacidade para determinado arquivo são bem comportados.

@nueverest como @jcgruenhage disse, uma vez que o usuário tenha acesso a um arquivo e possa descriptografá-lo, ele pode copiá-lo para um pendrive e publicá-lo em outro lugar.

Para mim, o mais importante é a propriedade --- quero ter certeza de que o arquivo foi modificado por alguém em quem confio. Uma maneira de fazer isso é criptografar o arquivo e usar a chave de descriptografia como parte do nome do arquivo --- então, uma vez que a soma de hash seja calculada para o arquivo descriptografado, saberei que apenas quem conhece a chave de criptografia pode fazê-lo .

Provavelmente não é a melhor maneira, mas está implementado em algum lugar?

Arquivos nomeados por caminhos /ipfs (por exemplo, /ipfs/QmSVyMxF5W5NFTJxKWhhdVjqnhhFmsqjFgSrbPovp5bzwF) são imutáveis, então isso não deve ser um problema. Arquivos nomeados por um caminho /ipns/... são mutáveis, mas são assinados pelo autor (o proprietário do nome IPNS).

No entanto, se você estiver obtendo /ipfs/... caminhos fora de banda e quiser determinar a autoria, provavelmente precisará assinar os dados (pode ser feito com, por exemplo, gnupg).

Nota: Nós provavelmente iremos construir um sistema de arquivos mutável como SUNDR. Esse sistema de arquivos provavelmente carregará informações de autoria. Provavelmente também permitiremos metadados arbitrários no futuro (que poderiam, em teoria, conter informações de autoria).

@risen @jbenet Você pode descrever (ou link para a descrição) como os modelos de capacidade podem ser usados ​​para impedir que arquivos com permissão em um nó IPFS saiam desse nó, exceto para um solicitante autorizado? Existe um recurso de modelo de capacidade explícito no IPFS? Eu procurei por documentação sobre isso, mas não encontrei nada explícito.

Oi @vdods -- estamos deixando os problemas neste repositório abertos para fins de referência, mas solicitando que a discussão de acompanhamento aconteça em https://discuss.ipfs.io/ (que é monitorado ativamente). Por favor, poste lá - obrigado!