Децентрализованная идентификация - использование в эпоху передаваемых идентификаторов
Введение
Каждый из нас «вынужден» иметь несколько идентификаторов в Интернете. Каждая платформа или APP требует регистрации, поэтому у вас должно быть много имен пользователей и паролей. Согласно статистике GlobalWebIndex в 2017 году, человек имеет в среднем 7,6 счета. Если вы взглянете на количество APP в своем телефоне, вы, вероятно, поймете, почему.
Многие люди считают, что имена пользователей и пароли трудно запоминать, поэтому одно и то же имя пользователя и пароль используются в нескольких приложениях. Ну, это удобно, но это также создает проблемы безопасности. Если база данных с низкой степенью защиты скомпрометирована, информация об учетной записи больше не безопасна. Вероятно, это приведет к потере учетных данных и конфиденциальности пользователя.
Чтобы предотвратить это, правительства обязаны вкладывать большие деньги в защиту данных и конфиденциальность.
От: 2017 Глобальный отчет CODB от IBM
До 2018 года глобально нужно заплатить высокую цену в 3,86 миллиарда долларов США из-за нарушений данных.
Стоит отметить, что каждое предприятие, правительство или веб-сайт владеет вашей личной информацией индивидуально и формирует изолированные островки данных. Большая часть этих данных повторяется и неэффективна, а повторное хранение данных приводит к большей вероятности утечки данных. В то же время более точное профилирование пользователей затруднено из-за отсутствия критических данных или без глубокого всестороннего анализа. В настоящее время принято считать, что персональные данные продаются третьей стороне. Скандал с данными Facebook-Cambridge Analytica в этом году также подтвердил нам, что наши данные могут быть легко проданы третьей стороне, без ведома владельцев.
Все это можно отнести к следующим моментам:
- Механизм централизации не только создает данные, но также порождает незаконные действия, такие как нарушения целостности данных.
- Одна точка отказа более склонна к возникновению и, следовательно, создает риски.
- Пользователям не хватает ID-схемы, которая является безопасной и простой в использовании.
Нынешнее самое идеальное решение, которое мы придумали, - это децентрализованная идентификационная технология.
- Технология децентрализованного цифрового идентификатора
Технология Digital ID на самом деле не так сложна - она просто дает объекту идентификатор, который должен быть уникальным и не прослеживаемым. Распределенные идентификаторы существуют уже более 20 лет, и доступны такие методы, как UID, snowflake и ObjectID.
Поскольку блокчейн использует функцию Хэша в качестве основы для криптографической защиты, а хэш-значение имеет такие характеристики, как неконтролируемость и сильное противодействие, которое требуется многим ID-системам. Случайность и уникальность распределения Хэша, несомненно, являются лучшими, и прослеживаемость чрезвычайно сложна.
Фактически, децентрализованный цифровой идентификатор значительно превысил объем цифрового идентификатора. Я понимаю, что децентрализованный цифровой идентификатор должен иметь следующие характеристики:
- Децентрализация всего процесса означает не только распределение процесса генерации, но и децентрализацию в использовании его данных.
- Не только простой идентификатор и другие данные, но и более децентрализованное хранение персональных данных.
- Личная информация может быть интерактивной и управляться с помощью цифрового идентификатора.
Очевидно, что просто предоставление хэша не может соответствовать перечисленным выше функциям.
Первая проблема - безопасность и контроль доступа.
Это проблема, с которой сталкиваются все проекты с цифровыми идентификаторами. Если безопасность данных не может быть гарантирована, то нет реального приложения. Сам блокчейн неизменен. Все же, блокчейн еще имеет множество уязвимостей, с которыми приходится иметь дело.
1. Nothing-at-stake Attack (Атака без цели)
В проекте с цифровым идентификатором огромное потребление PoW-технологий не поддерживается, упор больше на консенсус PoS или PBFT. Существует проблема с консенсусами: майнинг может производиться из прошлых блоков, чтобы продлить цепь дольше, чем существующая, чтобы вмешиваться или незаконно получать письменную личную информацию.
2. Sybil атака
Из-за огромной стоимости KYC в проекте публичного цифрового ID становится рентабельно создавать поддельных пользователей для атаки. В некоторых проектах используется PBFT, который не имеет естественного защитного механизма против атак Sybil (в отличие от возможности того, что процесс Mining PW автоматически исключает поддельные идентификаторы для захвата прав на выставление счетов). Консенсус PoS также может противостоять атаке Сибил, но поскольку легко создать разрыв между богатыми и бедными, дискурсная власть попадает в руки небольшого количества людей, которые владеют большим количеством акций и могут манипулировать данными.
3. Уязвимость Smart Contract Attack
Многие из лицензий, связанных с цифровым идентификатором, требуют интеллектуальных контрактов, в то время как интеллектуальные контракты, такие как ERC20, не идеальны. Если интеллектуальные контракты не проверяются на безопасность и есть уязвимости, последствия будут ужасными. В отчете указывается, что в настоящее время существует тысячи известных уязвимостей интеллектуального контракта.
Если вы разрабатываете собственный смарт-контракт, то все еще есть проблемы с введением кода. Из-за ограничений рабочей силы, как правило, трудно найти ошибки после долгосрочной проверки, и трудно предсказать масштаб и последствия ошибки до того, как ошибка будет использована злоумышленниками.
Вторая - защита данных.
Защита личной конфиденциальности является главным приоритетом технологии цифровых идентификаторов. Он примерно разделен на два аспекта: защита конфиденциальности при использовании данных и защита от десенситизации обработки данных.
Поскольку сам блокчейн является только псевдо-анонимным, данные, которые часто вызывают, могут подвергаться мониторингу, что приводит к их утечке.
Кроме того, что информация, предоставляемая обеими сторонами, часто вызывает избыточность в подаче данных, для обеспечения достоверности данных, что также приводит к некоторой утечке информации. Например, когда указан идентификатор удостоверения личности ID, адрес часто является информацией, которую не желательно предоставлять.
Чтобы решить эту проблему, существуют две общие идеи: одна - доказательство с нулевым разглашением, а другая - кольцевая подпись. Нулевое разглашение может решить проблему утечки данных из-за избыточности, в то время как кольцевые подписи уменьшают проблему утечки идентичности по вероятности.
Концепцию доказательства с нулевым разглашением немного сложно понять, вкратце:
- Правильные факты всегда имеют большую вероятность быть подтвержденными.
- Неправильные факты могут быть указаны с минимальной вероятностью.
- Вы можете знать только правильное или неправильное, больше ничего.
Есть два приложения с блокчейн: одно - zk-SNARK, а zk-SNARK может гарантировать, что в процессе проверки верификатор ничего не узнает, за исключением того, что утверждение prover корректно. Нет необходимости многократного взаимодействия. Второй - пуленепробиваемый, что сопоставимо с SNARK или STARK, но они изначально поддерживают эллиптические кривые. Кроме того, в отличие от SNARK, Bulletproofs достаточно быстр, чтобы доказывать и проверять разумные размеры на типичном компьютерном оборудовании.
Кольцевая подпись относительно проста. Каждый раз, когда адрес отправителя и адреса других людей смешиваются открытым ключом, создается многозадачная подпись, и данные приобретаются с помощью многоподписи. Значение кольцевой подписи определяется из того факта, что множество адресов сконструировано в кольцевой структуре для подписи. Кольцевые подписи могут расширить целевую группу, которую слушатель должен прослушать, что значительно уменьшает вероятность угадывания истинного отправителя. Разумеется, в кольцевой подписи также возникает проблема реального плательщика, который оплачивает контракт.
Третья проблема - это десенсибилизация данных конфиденциальности.
В действительности существует необходимость в десенсибилизации данных. Во многих местах персональная конфиденциальная информация обрабатывается как *, но если десенсибилизация выполняется неправильно или ваша информация помещается в местах, которые легко угадать, ваша информация может быть легко раскрыта. Это означает, что данные не успешно десенсибилизированы. Целью десенситизации данных является размытие информации, которая может привести к экспозиции. Обычными методами являются категоризация и сжатие.
Для больших баз данных распространены k-анонимность, l-разнообразие и t-близость. Метод конфиденциальности T работает лучше всего, но определение t сложнее. Первые два имеют тенденцию к конфиденциальности, но их относительно легко достичь.
Новый подход, возникший в последние годы, - это дифференциальная конфиденциальность. Дифференциальная конфиденциальность - относительно прочная технология защиты конфиденциальности. Наборы данных, которые удовлетворяют дифференциальной конфиденциальности, могут противостоять любому анализу частных данных, поскольку это информационная безопасность.
Цель дифференциальной конфиденциальности - это проблема: данные одного человека неизвестны, поскольку они защищены, но целевые данные получаются путем дифференциальной обработки данных из 50 человек и 49, кроме целевого. При дифференциальной конфиденциальности разница в данных между 50 и 49 людьми не будет доступна из-за наличия соответствующего шума, что защитит безопасность отдельных целевых данных. Тем не менее, нынешний этап дифференциальной конфиденциальности по-прежнему требует совершенствования технологий.
Четвертая проблема - структура хранения и стоимость.
Проблема структуры хранилища является самой простой из этих проблем, поскольку сам блокчейн может предоставить блокчейн-структуру для хранения данных. Однако для расширенных цифровых идентификаторов (то есть не только основной информации, но и большого количества личной информации, хранящейся под одним идентификатором, указанной в качестве подпозиции) требуется специальная структура хранения.
Механизм разработки PoW в BTC непригоден для проектов, таких как цифровые идентификаторы, а высокие транзакционные издержки приводят к неприемлемому хранению данных даже в полях с добавленной транзакцией - 20 долларов США за сообщение. ETH предоставляет соответствующие ресурсы хранения, но высокий газ и ограниченный TPS не позволяют обрабатывать загрузку больших объемов данных цифрового идентификатора. Если дешевая и безопасная децентрализованная платформа хранения не может быть найдена, децентрализованный проект цифровых идентификаторов станет непростой задачей.
Общие проекты децентрализованного хранения включают IPFS, SIA и Storj. У всех их есть одна особенность: майнеры обеспечивают пространство для хранения, а пространство, доступное для пользователей, невелико.
Самая важная причина для использования децентрализованного хранилища - это файлы в обычном доменном имени Http. Перемещение базы данных веб-сайта или закрытие веб-сайта напрямую приведет к потере файла. В то же время централизованный сервер имеет ограничения пропускной способности, которые растягиваются под большим количеством требований. Сам сервер также уязвим для атаки.
SIA и Storj ближе к уровню приложений и могут рассматриваться как блокчейн + BitTorrent. После того, как платеж будет сохранен, данные будут нарезаны и сохранены на накопителе с недостаточным объемом, отмеченном хеш-значением и сохранены в нескольких экземплярах. Таким образом, данные могут быть восстановлены, даже если они атакованы. В то же время, чем быстрее сеть P2P, тем быстрее она может прорваться через центральный сервер.
IPFS предвзято относится к базовому уровню и надеется заменить Http новым протоколом взаимодействия гипермедиа нового поколения. Он объединяет в одну систему множество функций, таких как Git BitTorrent SFS и DHT.
Особенно стоит упомянуть DHT, распределенную хэш-таблицу. Например DHT, Kademlia может обрабатывать Хэш XOR данных для построения дерева, что повышает эффективность запросов до O (logn). S / Kademlia усиливает сопротивление атакам Сибил, одновременно повышая эффективность соединений между честными узлами. Это не только используется для IPFS, но и для хранения цифровых идентификаторов также может использоваться аналогичная архитектура.
Вторая часть этой статьи будет выпущена на следующей неделе.
Спасибо за прочтение.
** Немного обо мне_**
Сяолун Сюй, соучредитель DREP Foundation
Бывший ведущий разработчик QTUM, обладающий обширным опытом в области технологии blockchain и развития публичных блокчейнов. Технический советник нескольких блокчейн-проектов. Инструктор NODE Blockchain Accelerator
Бывший разработчик программного обеспечения в Microsoft и Tencent. Мастер Китайской академии наук.