Как Oraclize обрабатывает секрет TLSnotary?

Oraclize утверждает, что предлагает доказуемо честный безопасный поиск веб-страницы, используя TLSnotary ( служба, которая позволяет аудитору проверять, была ли определенная веб-страница точно получена)

Цель Oraclize заключается в том, чтобы сделать эту информацию доступной для интеллектуальных контрактов.

Но, насколько я понимаю, единственным фактором, обеспечивающим безопасность TLSnotary, является то, что лицо, выполняющее аудит, генерирует и удерживает секретный фрагмент данных до тех пор, пока проверяемый человек не предоставит им хеш полученной веб-страницы. Контракт, очевидно, не может генерировать и скрывать секрет. Разве это не означает, что сам контракт не может проверить доказательство TLS?

Кажется, что необходимо уточнить, как именно Oraclize обрабатывает секрет TLSnotary.

Oraclize также предлагает веб-инструмент, позволяющий вам играть роль аудитора. Может ли несколько человек одновременно проверять одно и то же доказательство TLS? И предположим, что я do каким-то образом управляю обманом обмана Oraclize. Как я могу доказать это третьему лицу?

Проще говоря, насколько я могу доверять службе Oraclize?

Не принимайте мои вопросы не так - я очень взволнован идеей оракулов, фактически доказывающих их претензии. Я просто хочу задать трудные вопросы!

16 голосов | спросил Jeff Coleman 21 Jam1000000amThu, 21 Jan 2016 10:51:58 +030016 2016, 10:51:58

3 ответа


20

Oraclize сохраняет секрет TLSnotary в Amazon Виртуальная машина веб-служб (AWS) .

Используя описанные методы здесь , они могут предоставить некоторые дополнительные гарантии относительно программное обеспечение, запущенное в экземпляре AWS, и когда /было ли оно изменено с момента его инициализации. «Доказательства честности», которые они предоставляют (и позволяют вам проверить с помощью своего веб-инструмента ), являются подписали аттестации этого экземпляра AWS, что имело место правильное доказательство TLS (а не само доказательство TLS, которое было бы невозможно для третьей стороны после факта).

Для обычного пользователя, вероятно, сложно понять, что это означает с точки зрения безопасности и доверия, поэтому позвольте мне немного рассказать о последствиях этой техники для безопасности.

Основные преимущества подхода Oraclize:

  • Привлекая оракул AWS , Oraclize усложнил службу поиска данных лгать о содержимом веб-страницы. Таким образом, этот подход меньше , чем чисто доверенный сервис оракула .
  • Кроме того, тот, кто компрометирует интеллектуальный контракт Oraclize, автоматически не получает возможность подделывать результаты (при большинстве сервисов oracle компрометация ключа или смарт-контракта позволит вам подделывать произвольные результаты)
  • Наконец, проверка подписи AWS-оракула является сравнительно «дешевой» вычислительной операцией, поэтому «честные доказательства» Oraclize потенциально могут быть проверены в цепочке при условии, что TLS-недоразвитый контент достаточно короткий (например, вызов API).

Основные недостатки подхода Oraclize:

  • Амазонка сама или любой, кто может взломать /подавать вызов платформе AWS Amazon, может получить возможность подделать «доказательства честности», украв закрытый ключ AWS oacle . Однако этот объект, вероятно, также должен получить контроль над сервером API Oraclize и /или интеллектуальным контрактом, если они захотят разбить приложения, основанные на сервисе Oraclize.
  • Если вы do поймаете кого-то, фальсифицируйте доказательства Oraclize, нет способа доказать это кому-либо еще , если вы сами не сможете получить закрытый ключ AWS oracle. Для большей ясности: если вы извлекаете некоторые данные из Oraclize, и это, очевидно, неправильно, общественность не знает, является ли источник или проблема с Oraclize сервером. Либо можно просто обвинить другого.
  • Не забывайте, что при получении веб-страницы через оракул вы все еще позволяете веб-серверу отвечать всем, что он хочет . Поэтому для сторонних злоумышленников было бы намного проще просто скомпрометировать сервер, если вы хотите разорвать приложение, использующее Oraclize (т. Е. Веб-сайт обмена, если приложение использует его для рыночных цен). С этой точкой (и предыдущей) в виду, это гораздо меньше хлопот, чтобы просто предоставить поставщику информации be oracle . Oraclize следует рассматривать как резерв для получения информации от источников, которые не знают о цепочке. Источники с блочной цепью должны просто подписывать свою информацию напрямую.
  • Во многих ситуациях поиска информации (где задействованы только две стороны) для сторон самой транзакции будет гораздо больше смысла действовать как клиент и аудитор в доказательстве TLS . Это дает вам все гарантии Oraclize без каких-либо дополнительных рисков.

Things Oraclize может сделать для улучшения:

  • предлагают большую, на цепочку щедростьдля успешного извлечения своего личного ключа AWS oracle.
  • убедитесь, что их код оракула AWS затвердел против атак сторонних каналов vm (т. е. операции подписи - это постоянное время и память и т. д.).
  • настраивать различные простые статические https-страницы и предлагать большую сетевую награду, которая выплачивает любой адрес, полученный с этих страниц через API Oraclize. Это будет одновременная ставка от их имени против компрометации защищенных механизмов Oraclize и против того, что злоумышленники могут скомпрометировать сервер Oraclize-run.

ТЛ; др:

Oraclize лучше, чем ничего для извлечения содержимого с веб-страницы HTTPS. Вероятно, это самое лучшее, что мы можем сделать сейчас, чтобы сделать заявления public о содержимом защищенных веб-страниц. Но это не должно рассматриваться как окончательное или полностью безопасное решение для поиска веб-контента. Во многих случаях использование ваших TLS-приложений напрямую зависит от использования Oraclize. И наличие поставщика информации, подписывающего их контент, напрямую превосходит как во всех случаях! Oraclize - достойный шаг вперед, но это не окончательное решение . Будьте осторожны, чтобы вы использовали их сервис таким образом, чтобы он соответствовал уровню риска вашего приложения!

ответил Jeff Coleman 27 FebruaryEurope/MoscowbSat, 27 Feb 2016 22:05:00 +0300000000pmSat, 27 Feb 2016 22:05:00 +030016 2016, 22:05:00
4

То, как я был объяснен нотариусом TLS (автором этого в IRC), было то, что третья сторона должна хранить данные, чтобы предотвратить использование источником данных и заставить их казаться, что ваши захваченные данные на самом деле не аутентичны , Другими словами, ложь «Я этого никогда не говорил!» от пользователей веб-хостинга.

На самом деле это безопасно, потому что, когда вы переходите на защищенный сайт HTTPS, вы можете убедиться, что они являются компанией X (если вы проверяете сертификаты). TLS Нотариус по существу способен записывать эти байты таким образом, что вы можете воспроизвести их позже, чтобы снова подтвердить подлинность байтов! Очень изобретательно. (Но математика того, как это делается в документе, выходит выше моей головы. https://tlsnotary.org/TLSNotary. PDF )

ответил linagee 21 Jam1000000amThu, 21 Jan 2016 11:41:52 +030016 2016, 11:41:52
0

Как отмечает @JeffColeman в комментарии, TLSnotary - это интерактивный протокол, аудитор должен хранить секретную часть какой-либо части основного ключа для работы всего решения. Если аудитор знает полный мастер-ключ, проверяемая сторона сможет вычислить ключ сервера HMAC, а затем он сможет что-либо изменить, просто восстановив новый HMAC.

Но для Oraclize они в основном являются аудиторами и проверяемыми. Таким образом, проблема заключается в следующем: как я могу уверен, что аудитор и аудитория не сговорены, т. Е. Oraclize не обманывает?

В целом, чрезвычайно сложно доказать, что аудитор и аудитор вступили в сговор. Потому что для того, чтобы доказать, что они обманули, нам нужно проверить, что проверяемая уже известна секретная часть главного ключа во время передачи. И поскольку секрет в конечном итоге будет опубликован (потому что нам нужно его выполнить проверку), как мы можем знать , в какое время проверяемая знает секрет?

Oraclize решает эту проблему, запустив аудитора в AWS и публикуя информацию об аудиторе и времени работы аудитора для общественности, чтобы вы могли проверить целостность среды аудитора. Хотя относительно легко обнаружить изменения , но если вы действительно не проверяете исходный код и конфигурацию всей среды, все равно трудно убедиться, что аудитор только делает что он должен делать и ничего больше (никаких ошибок, независимо от того, предназначено или нет). Вот почему мы только сказали, что это , вероятно, честный

ответил GummyBear21 25 Jam1000000amThu, 25 Jan 2018 07:58:42 +030018 2018, 07:58:42

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132