В Corda, как два узла могут доказать друг другу, что они оба знают часть информации?

Question

Я хочу написать поток Corda, в котором две стороны выполняют транзакцию только в том случае, если они оба могут доказать, что они разделяют общую часть информации. Схема потока будет выглядеть следующим образом:

@InitiatingFlow
@StartableByRPC
class ChallengeResponseFlow(val otherParty: Party, val proofOfKnowledge: Int) : FlowLogic<Unit>() {

    @Suspendable
    override fun call() {
        val otherPartySession = initiateFlow(otherParty)
        otherPartySession.send(proofOfKnowledge)
        val theirProofOfKnowledge = otherPartySession.receive<Int>().unwrap { theirProofOfKnowledge -> theirProofOfKnowledge }
        verifySecretValue(theirProofOfKnowledge)

        TODO("Challenge-response passed. Continue with flow.")
    }

    private fun verifyTheirProofOfKnowledge(theirProofOfKnowledge: Int) {
        TODO("Write verification logic.")
    }
}

Два вопроса:

• Что может быть здесь доказательством знания, чтобы доказать, что я знаю тот же секрет, что и мой контрагент?
• Как я могу проверить, что мой контрагент знает тот же секрет, основываясь на доказательстве, которое они мне прислали?

Важно, что во время этого протокола ответа на вызов, секрет никогда не раскрывается.

Answer 1

В зависимости от ваших требований существуют различные стратегии:

1. Предполагая, что секрет имеет достаточную энтропию (т. Е. Не менее 128 бит), обе стороны могут выбрать случайное nonce и отправить SHA3-256(secret, nonce) или SHA2-256d (двойной хэш) или даже лучше HMAC вместе со своими nonce другой стороне.

Примечание A: Как вы заметили, я пропустил простой SHA256, так как он подвержен атакам с расширением длины .

ПримечаниеB: отправка половины хэша, как уже упоминалось @ Kid101, все еще будет работать, но это снижает уровень безопасности, поэтому одноразовый подход считается более безопасным и элегантным.

ПримечаниеC: Подход одноразового использования предоставляет дополнительное (возможно желаемое) свойство несвязанности, согласно которому злоумышленник не может определить, повторно используется ли один и тот же secret в двух разных транзакциях / потоках. Нужно всегда генерировать новый случайный одноразовый номер.

2. Однако существуют случаи, когда секрет не обладает достаточной энтропией или вообще не является случайным (то есть счетчик или предсказуемый String, такой как слабый пароль или идентификатор пользователя). Затем один (человек посередине) может просто перебрать простой хэш или подход MAC (даже когда применяется одноразовый номер), чтобы легко извлечь «слабый» секрет. Решения этой проблемы являются более сложными и требуют некоторого шифрования (то есть отправка хэшированных сообщений по безопасному каналу или с использованием протокола аутентификации ключа с проверкой пароля ).

ПримечаниеD: Узлы Corda в любом случае подключены через TLS, но если вам нужно защитить данные в покое (т. Е. Контрольные точки), следует использовать дополнительный уровень шифрования.

3. Если кто-то хочет обеспечить защиту от атак воспроизведения, требуется протокол вызова-ответа. Под атакой воспроизведения мы подразумеваем, что тот же самый одноразовый номер используется повторно преднамеренно (то есть предыдущий токен аутентификации был каким-то образом скомпрометирован и повторно использован в будущей попытке аутентификации). Одна хитрость для первого случая (секрет с достаточной энтропией) состоит в том, чтобы получить вызывающий одноразовый номер от контрагента и использовать этот одноразовый номер для токена аутентификации SHA3-256(secret, nonce). Таким образом, каждый клиент использует одноразовый номер, полученный другой стороной.

4. Расширяя вышеупомянутое решение проблемы-ответа, иногда рекомендуется использовать оба одноразовых номера, например,

Партия А отправляет SHA3-256(secret, noncefromPartyA, noncefromPartyB)

и

Партия B отправляет SHA3-256(secret, noncefromPartyB, noncefromPartyA)

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

ПримечаниеE : Мы должны убедиться, что noncefromPartyA != noncefromPartyB, потому что тот, кто отвечает вторым, может просто повторно использовать (переслать) тот же токен аутентификации с первой стороной (снова тип повторная атака).

ПримечаниеF : В том же ключе мы подчеркиваем, что порядок одноразовых номеров в вышеуказанных хэшах должен быть другим, чтобы снова защищать от внутренних атак воспроизведения, даже когда мы используем разные одноразовые номера для каждого пользователя!

Answer 2

Я могу хешировать свой секрет с помощью SHA256, отправив первые 128 бит на другую сторону, и пусть другая сторона проверит, совпадают ли его секреты с хешем SHA256 с его первыми 128 битами. затем он может отправить свою вторую половину первой стороне, чтобы проверить, совпадает ли она с его.