@Joel Как SGX может помочь здесь?

ы узнали, что корда не защищена от несанкционированного доступа, но является очевидной. Таким образом, если один из узлов манипулирует состоянием непосредственно в базе данных, другие узлы смогут обнаружить и пометить его, если это состояние использовалось в последующих транзакциях. Тем не менее, наши результаты испытаний не соответствовали нашим ожиданиям. Corda не помечала состояние, которое было изменено, и фактически оно записало новое состояние с измененными данными во всех узлах-участниках.Предпосылки

Закомментируйте проверки контрактов: мы прокомментировали код контракта, чтобы проверить, обнаружено ли вмешательство в данные в Corda, без явной проверки на командном уровне.: Шаги для тиражирования:

Начать обязательство Cordapp.

Создать 3 обязательства между Стороной A и Стороной B (100 THB, 256 THB и 100 THB)

Отредактируйте таблицу VAULT_STATES в базе данных Стороны B, посмотрев на различия между гексами.

Обязательства с разной суммой слева и два обязательства с одинаковой суммой справа. От редактора, когда они находятся в одинаковом количестве, есть 2 различия (предположительно, линейный идентификатор и временная метка связаны), а когда они в разном количестве, 3-е несоответствие показано слева.Перезапишите конкретную часть с меньшим значением, обновите хранилище, используя SQL в хранилище Стороны B:

После этого обновления проверьте хранилище Стороны B. Суммы будут изменены на 100 THB по всем 3 обязательствам.

Однако в хранилище Стороны А будут отображаться исходные суммы (100, 256, 100), поскольку данные не были изменены в хранилище Стороны А.

Передать ВСЕ обязательства от Стороны B к Стороне C

Результат обязательств по передаче: у Стороны B больше нет обязательств

Результат обязательств по передаче: Сторона C получит все обязательства Стороны B (100 THB за все, т.е. подделанные данные были переданы новой стороне)

Результат обязательств по передаче: хранилище Стороны А также будет обновлено подделанными данными. Он не может идентифицировать или помечать несанкционированные данные.

Как заставить узлы-участники Corda обнаруживать несанкционированные состояния? я пропустил некоторые настройки при настройке узла?

Я прочитал всю вашу разоблачение дважды, но до сих пор не обнаружил вопрос.

 Rickky1321 дек. 2017 г., 05:51
Просто чтобы вы знали, что мы с большим интересом смотрим на это здесь, на r3, но это начало курортного сезона, поэтому пока не ожидайте подробного ответа.
 Robby Cornelissen21 дек. 2017 г., 05:48
Вопрос в том, как заставить узлы-участники Corda обнаруживать подделанные состояния?
 Richard Green21 дек. 2017 г., 17:04
Боюсь, что это обсуждение может занять некоторое время, потому что большинство из нас уходит в отпуск с этого дня.

Ответы на вопрос(1)

Решение Вопроса

что вы сделали здесь. Однако мне не ясно, что это ошибка.

Вы говорите, что прокомментировали логику проверки контракта. Похоже, что то, что могло случиться, таково:

Отредактируйте таблицу состояний для хранения поврежденного состояния.

Создайте транзакцию с INPUT = указатель на предыдущее правильное состояние. OUTPUT = (поврежденное состояние) + изменить, чтобы сохранить новое поле владельца.Эта транзакция подписана и передана.Эта транзакция

было бы были признаны недействительными и отклонены при попытке передачи Стороне C, потому что это был бы незаконный переход состояния: числа не сбалансированы. Но вы закомментировали код, который проверяет это! Так что ничто нигде не говорит о том, что вам не разрешается просто изменять размер обязательства, когда вам нравится ... Корда не знает этого неявно, если вы закомментируете код, содержащий эти знания. Таким образом, с точки зрения IOU-приложения изменение размера при переносе теперь вполне законно.Вот вопрос - если вы оставите приложение в покое и не измените его исходный код, обнаружено ли вмешательство? Если ответ все еще «нет», тогда нам нужно провести еще одно расследование.

как INPUT по-прежнему указывает на предыдущее правильное состояние, когда таблица состояний уже содержит поврежденное состояние? Разве ввод не запрашивается / десериализуется откуда-то еще? Можете ли вы посоветовать, как мне доказать и проверить, что, если входные данные каким-либо образом повреждены, проверка resolDependency во время подписи подписей вызовет ошибку на живых узлах и обеспечит происхождение (также одна из причин, по которой я закомментировал код контракта для изоляции доказывая это)

 Rickky1303 янв. 2018 г., 05:22
это значитstateAndRef.ref проверяет код контракта на состояниях из хранилища транзакций? Если код контракта требует некоторой проверки в полях состояния ввода, т.е. в этой строкеtx.verify(serviceHub)TX сначала будет преобразован вval input = tx.inputsOfType<Obligation>().single() который запрашивает состояния из хранилища транзакций на основе хешей tx, которые создали состояния? (Не хранилище, в котором хранятся состояния, которые были повреждены)LedgerTransactionЭто правильно :) Хранилище не используется при проверке транзакции.
 Balaji More01 авг. 2018 г., 16:23
Проблема подделки данных
 Rickky1323 дек. 2017 г., 05:39
Каждый узел хранит состояния в двух местах - самостоятельно в своем хранилище и как часть транзакций, сгенерировавших их в своем хранилище транзакций. Когда вы строите транзакцию, вы не включаете входные данные напрямую. Вместо этого вы включаете ссылки на состояние ввода (см.
 Joel04 янв. 2018 г., 12:34
@Joel Как SGX может помочь здесь?

Ваш ответ на вопрос