Ipfs: 권한

추가 조사에서 누락된 유일한 것은 blob의 소유권(없음)과 소유자가 제어하는 ​​목록(또는 여러 개)을 기반으로 한 읽기 권한(없음이 아닌 경우)뿐이라고 생각합니다. 이것은 기본 fs를 수정하지 않고 IPFS 위에 구축할 수 있습니다.

대신 기능을 사용하는 것이 좋습니다. 순진한 예: 일부 비밀로 파일을 암호화하고 "읽기 권한"이 있는 사람들과 비밀을 공유합니다.

정확히. 모자. e-rights 및 Tahoe-LAFS 보기

—
사서함에서 보낸

2015년 9월 4일 금요일 오후 4시 46분, Mourad De Clerck 알림 @github.com
썼다:

대신 기능을 사용하는 것이 좋습니다. 순진한 예: 일부 비밀로 파일을 암호화하고 "읽기 권한"이 있는 사람들과 비밀을 공유합니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/ipfs/ipfs/issues/86#issuecomment -137755902

권한을 관리하기 위한 암호화는 매우 나쁜 생각입니다. 낙관적인 시나리오에서는 잘 작동하지만 현실에서는 잘 유지되지 않습니다.

예를 들어 암호화된 파일이 여러 노드에 분산되어 악의적인 의도를 가진 사람에게 도달했다고 가정하면 파일을 해독하는 데 어느 정도 노력을 기울일 수 있습니다. 낙관적인 세상에서는 실패하고 모두가 행복합니다. 응!

현실 세계에서 파일이 생성된 지 얼마 되지 않았다면 그 이후로 암호화 알고리즘의 결함이 발견되었을 가능성이 있습니다. 또는 새로운 특수 암호 해독 하드웨어가 널리 사용 가능하게 될 수도 있습니다. 이렇게 하면 암호 해독 프로세스의 복잡성이 크게 줄어듭니다. 파일을 진정으로 소유하는 사람은 아무도 없기 때문에 기존 파일을 가져와서 새롭고 안전한 알고리즘으로 암호화된 새 버전으로 교체할 방법이 없습니다. 이와 같은 작업을 수행할 수 있더라도 악성 노드는 이전 버전의 파일을 유지하지 않을 것임을 알려줍니다.

결국 보안 및 개인 정보 보호와 관련하여 파일이 네트워크를 떠나는 것을 막는 것보다 좋은 것은 없습니다.

파일 권한보다는 노드 수준에서 하는 것이 더 의미가 있지 않을까 생각합니다. 기본적으로 노드는 화이트리스트/블랙리스트 패러다임에 따라 다른 노드의 연결을 거부할 수 있어야 합니다. 이것은 사람들이 사설 비트 토렌트 트래커와 약간 유사한 사설 IPFS 네트워크를 만들어 악의적인 노드로의 누출을 피하면서 민감한 데이터를 공유할 수 있도록 합니다.

알려진 악성 노드를 자동으로 차단하기 위해 IPFS 자체에 저장된 전 세계적으로 분산된 노드 블랙리스트를 고려할 수도 있습니다. 하지만 노드 ID가 새 키 쌍을 통해 간단히 다시 생성될 수 있다는 점을 고려하면 이것이 얼마나 유용한지 모르겠습니다.

또한 암호화가 이를 수행하는 가장 간단한 방법이라는 데 동의합니다.
암호화 체계는 해킹될 수 있지만 노드도 해킹될 수 있습니다. 사용자는 단순히 필요
액세스 제어를 제공하려고 할 때 이러한 가능성을 인식
얼룩에.
2015년 9월 9일 오후 6시 48분에 "Etienne Maheu" [email protected] 이 작성했습니다.

권한을 관리하기 위한 암호화는 매우 나쁜 생각입니다. 그것은 잘 작동합니다
낙관적인 시나리오지만 현실에서는 잘 유지되지 않습니다.

예를 들어 암호화된 파일이
여러 노드에서 악의적인 의도를 가진 사람에게 도달하면
파일을 해독하는 데 약간의 노력을 기울이십시오. 낙관적인 세상에서 그들은
실패하고 모두가 행복합니다. 응!

실제 세계에서 파일이 얼마 전에 생성된 경우
그 이후로 암호화 알고리즘의 결함이 발견되었을 가능성이 있습니다.
또는 새로운 특수 복호화 하드웨어가 널리 보급될 가능성이 있습니다.
사용 가능. 이렇게 하면 암호 해독의 복잡성이 크게 줄어듭니다.
프로세스. 아무도 파일을 실제로 소유하지 않기 때문에 파일을 가져올 방법이 없습니다.
기존 파일을 암호화한 새 버전으로 교체합니다.
새롭고 안전한 알고리즘. 이런 걸 할 수 있다 해도 뭐
악성 노드가 파일의 이전 버전을 유지하지 않을 것임을 알려줍니다.
그래도.

결국 파일이 네트워크를 떠나는 것을 막는 것보다 나은 것은 없습니다.
보안 및 개인 정보 보호와 관련하여.

파일권한 대신 하는게 더 의미있을듯
노드 수준에서. 기본적으로 노드는 연결을 거부할 수 있어야 합니다.
화이트리스트/블랙리스트 패러다임을 기반으로 다른 노드에서. 이렇게 하면
사람들은 개인 비트 토렌트와 약간 유사한 개인 IPFS 네트워크를 만듭니다.
악의적인 사용자에게 유출되는 것을 방지하면서 민감한 데이터를 공유하기 위한 추적기
마디.

어쩌면 우리는 전 세계적으로 분산된 노드 블랙리스트를 고려할 수도 있습니다.
알려진 악성 노드를 자동으로 차단하기 위해 IPFS 자체에 저장됩니다.
그러나 이것이 노드 ID를 고려할 때 얼마나 유용한지 모르겠습니다.
새 키 쌍을 통해 간단히 다시 생성할 수 있습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/ipfs/ipfs/issues/86#issuecomment -138988589.

@ekg 차이점은 노드 보안 방식이나 화이트리스트 시스템 자체에 결함이 있는 경우 네트워크에서 영향을 받는 모든 노드를 "사용자가 제어"하기 때문에 업데이트될 수 있다는 것입니다. 노드를 신뢰하기로 선택한 경우 안전한지 확인하는 것은 사용자에게 달려 있습니다. 결함이 나타난다면 데이터가 유출되었다는 의미가 아니라 최대한 빨리 수정해야 한다는 의미입니다. 분산 파일 시스템의 암호화와 관련하여 이 작업을 수행할 수 없습니다. 파일이 깨진 암호화를 사용하는 경우 두 번째 기회가 없습니다.

@kawazoe 기능 모델을 읽어보십시오. 모든 단일 권한 체계는 기능 시스템에 표시될 수 있으므로 _엄격히 우수한_ 시스템입니다. 서류가 풍부하다.

노드는 화이트리스트/블랙리스트 패러다임을 기반으로 다른 노드의 연결을 거부할 수 있어야 합니다. 이것은 사람들이 사설 비트 토렌트 트래커와 약간 유사한 사설 IPFS 네트워크를 만들어 악의적인 노드로의 누출을 피하면서 민감한 데이터를 공유할 수 있도록 합니다.

이것은 이미 계획되어 있지만 직교합니다.

@jbenet 능력이 나쁘다는 말은 아닙니다. 이 모델을 사용할 계획을 세우는 것이 좋습니다. 내가 말하려는 것은 액세스 기능과 읽기 기능(어느 수준이나 구현 방식에 관계없이) 사이에 뚜렷한 차이가 있으며 데이터를 암호화하는 것만으로는 둘을 구별하기에 충분하지 않다는 것입니다.

특정 파일을 검색할 수 있는 노드를 제어하는 ​​노드가 있어야 합니다. 일부 시나리오에서는 파일 암호화가 좋지 않습니다. 몇 가지 예:
사람들이 콘텐츠에 액세스하기 위해 비용을 지불해야 하는 미디어 서비스가 있습니다. 대역폭을 절약하기 위해 IPFS를 사용하는 것이 합리적일 것입니다. 지불한 사람만 적어도 노드와 정직한 사용자의 노드를 통해 파일에 액세스할 수 있도록 보장할 수 있습니다. 파일이 암호화로만 보호된다면 매체당 키를 추출하는 단일 사용자만 필요하고 해적은 IPFS를 통해 콘텐츠를 훔칠 수 있습니다. 비동기식 암호화가 없으면 어떤 사용자가 키를 배포했는지조차 알 수 없으며 비동기식 암호화를 사용하면 IPFS의 이점을 얻을 수 없습니다. 다시 생각해 보십시오.

이를 구현하는 방법은 파일을 요청받은 노드가 파일에 액세스하려는 노드가 그렇게 할 수 있는지 여부를 묻는 일부 권한을 요청하고 이에 따라 행동하는 것입니다. 그렇게 하는 것도 너무 어렵지 않아야 하며 분명히 사용자가 있을 것입니다.

@jcgruenhage 네트워크의 모든 사용자가 동일한 개인 네트워크에 있게 할 수 있습니다. (사설 네트워크에 대한 자세한 내용은 https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-284341649 참조)

그 외에도 이것을 특별한 비트스왑 확장으로 구현할 수 있지만 기본 네트워크에 연결되어 있는 동안 암호화되지 않은 '비공개' 콘텐츠를 사용하려고 하는 몇 가지 이상한 문제가 발생합니다. '허용된 그룹' 외부에 있는 누군가가 다른 수단을 통해 파일을 가져오고(그리고 동일한 해시를 가짐) 허용된 그룹의 노드가 파일을 가져오면(아마도 다운로드한 다른 아카이브의 일부일 수 있음) 그런 다음 보호되지 않는 소스에서 가져온 파일을 요청한 다른 피어에게 파일을 제공해야 합니까?

사설 네트워크 기능은 흥미롭게 보이지만 이 콘텐츠에 액세스하기 위해 사람들이 완전히 별도의 노드를 갖게 될 것이고 그것이 대부분의 사람들이 원하는 것인지 의심스럽습니다. 또한 파일을 가져오는 사람을 제어하는 ​​중앙 기관 대신 손상되어야 하는 단일 키가 있습니다.

노드가 다른 곳에서 파일을 가져온 경우 파일을 공유해야 하는지 여부, 파일에 액세스가 제한되어 있다는 것을 어떻게 알 수 있습니까? 그런 다음 공유하는 것이 좋은 것 같습니다. 왜냐하면 누군가가 파일을 "도용"하는 경우에만 파일을 고정한 서버 노드와 정직한 사용자의 노드가 다운로드를 하지 않는다는 것뿐이기 때문입니다. 모든 노드에서도 다운로드할 수 있지만 정직하지 않은 사용자에게서만 다운로드할 수 있기 때문에 매우 빠릅니다.

@jcgruenhage 사설망이 필요한 불편함에 동의합니다.

또한 부정직한 사용자가 데이터를 해독할 때 즉시 이 데이터를 공용 네트워크에 업로드할 수 있기 때문에 사설 네트워크가 얼마나 도움이 되는지 명확하지 않습니다. 무언가가 이것을 막는다면 저를 수정하십시오.

사설 네트워크에 최대 2개의 노드가 있는 경우 정직한 노드는 다른 노드가 부정직하게 데이터를 누출하고 있음을 알 수 있습니다. 사설 네트워크에서 두 개 이상의 노드를 허용하면 누출 결정성이 손실됩니다.

2노드 사설망에서도 정직한 노드는 데이터가 누출되고 있다는 사실을 즉시 알지 못합니다. 시간이 지나면 데이터가 은하계의 절반에 도달할 수 있습니다.

가능한 솔루션은 파일 복호화 중에 암호화된 노드 ID/추적자 ID를 추가하는 것입니다. 따라서 각 사용자는 고유한 추적 프로그램/노드 ID를 포함하는 각 파일의 약간 수정된 사본을 얻습니다. 해독된 파일은 항상 원본과 다르지만 원본은 변경 불가능하고 검증 가능한 상태로 유지됩니다.

사설 네트워크와 관련된 센티넬 노드는 이러한 추적자 값에 대해 공용 네트워크를 모니터링할 수 있습니다. 이러한 방식으로 적시에 누출 원인을 감지할 수 있습니다.

이것은 한 개인 네트워크의 노드가 다른 개인 네트워크로 데이터를 누출하는 것을 방지하지 못합니다.

사용자가 파일을 공유하는 것을 막을 수는 없지만 이를 위해 인프라를 사용하는 것을 막을 수는 있지만 현재로서는 아직 이를 수행하는 분산 파일 배포 시스템이 없습니다.

@jcgruenhage hrm... 흥미로운 사용 사례입니다. 각자 참여할까
노드는 요청되는 각 블록에 대해 서버에 묻습니까? 아니면 인증을
서버는 허용된 피어의 큰 목록과 그들이 무엇인지 보냅니다.
사용 허용?

2017년 6월 2일 금요일 09:19 1월 Christian Grünhage [email protected]
썼다:

사용자가 파일을 공유하는 것을 막을 수는 없지만
이를 위해 인프라를 사용하는 것을 방지하지만 현재로서는
아직 이 작업을 수행하는 분산 파일 배포 시스템입니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/ipfs/ipfs/issues/86#issuecomment-305836646 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ABL4HGtd8flt7agdikQeIrSk59vnTZzvks5sADYlgaJpZM4F3vN7
.

사설망 기능은 PNet 피어에 대한 완전한 신뢰 개념을 기반으로 구축되었습니다.

다음 단계는 일부 노드가 일부 파일에 액세스하도록 허용할 수 있는 기능 시스템이 될 수 있습니다. 해당 스키마의 악의적인 행위자는 주어진 파일에 대한 기능이 있는 다른 노드가 잘 동작한다는 점을 감안할 때 자신이 사용할 수 있는 데이터만 누출할 수 있습니다.

@jcgruenhage 가 말했듯이 @nueverest 는 사용자가 파일에 액세스하고 암호를 해독할 수 있으면 USB 스틱에 복사하여 다른 곳에 게시할 수 있습니다.

나에게 더 중요한 것은 소유권입니다 --- 파일이 내가 신뢰하는 사람에 의해 수정되었는지 확인하고 싶습니다. 이를 수행하는 한 가지 방법은 파일을 암호화하고 암호 해독 키를 파일 이름의 일부로 사용하는 것입니다 --- 따라서 암호 해독된 파일에 대해 해시 합계가 계산되면 암호화 키를 아는 사람만 수행할 수 있음을 알 수 있습니다. .

아마도 최선의 방법은 아니지만 어딘가에 구현되어 있습니까?

/ipfs 경로로 이름이 지정된 파일(예: /ipfs/QmSVyMxF5W5NFTJxKWhhdVjqnhhFmsqjFgSrbPovp5bzwF)은 변경할 수 없으므로 문제가 되지 않습니다. /ipns/... 경로로 명명된 파일 은 변경할 수 있지만 작성자(IPNS 이름의 소유자)가 서명합니다.

그러나 대역 외 /ipfs/... 경로를 얻고 저작권을 확인하려는 경우 데이터에 서명해야 할 수 있습니다(예: gnupg로 수행 가능).

참고: 우리는 결국 SUNDR과 같은 변경 가능한 파일 시스템을 구축할 것입니다. 해당 파일 시스템에는 저작권 정보가 포함될 가능성이 높습니다. 우리는 또한 미래에 임의의 메타데이터를 허용할 것입니다(이론적으로는 저자 정보를 전달할 수 있음).

@risen @jbenet IPFS 노드의 권한이 있는 파일이 권한 있는 요청자를 제외하고 해당 노드를 떠나는 것을 방지하기 위해 기능 모델을 사용하는 방법을 설명(또는 설명에 대한 링크)할 수 있습니까? IPFS에 명시적 기능 모델 기능이 있습니까? 나는 이것에 대한 문서를 검색했지만 명시적인 것을 찾지 못했습니다.

안녕하세요 @vdods -- 우리는 이 리포지토리의 문제를 참조용으로 남겨두고 있지만 후속 논의가 https://discuss.ipfs.io/ 에서 일어나도록 요청합니다(이는 적극적으로 모니터링됨). 거기에 게시하십시오 -- 감사합니다!