Комментарии 6
Немного запутан сам метод, но, как я понял, один из его плюсов - это в том числе и совместимость маломощными устройствами интернета вещей, когда из-за ограничений на энергопотребление, а значит, и скорость обработки данных, может пострадать безопастность передачи данных между таким устройствами, потому что им придется использовать менее криптостойкие алгоритмы.
А данный механизм нивелирует подобные ограничения.
Вспомнил, нам в универе рассказывали про похожий но сильно упрощенный способ, когда проверяющая сторона отправляет проверяемой операцию, которую надо проделать с секретом и получить бинарный ответ, затем сверяет ее результат со своим, таким образом после первой итерации уверенность в валидности всего 0.5, но при каждой следующей увеличивается и при достижении необходимой доступ предоставляется. Главная фишка как и в статье: не передается ни сам секрет, ни даже его хэш.
Чем это принципиально отличается от того, что уже сейчас делает, например, Google Authenticator?
Там, насколько я понимаю, сначала происходим обмен некоторыми seed'ами, а затем из них последовательно генерятся коды. А в описанной схеме проверяемая сторона заранее не знает какой челлендж придет от проверяющей
Google Authenticator посылает некий код сервису и клиенту. Клиент должен сказать его сервису, а сервис проверят с Google, совпал код или нет. Срок действия кода - 1 минута, потом код меняется.
Проверяемая сторона заранее не знает точно, какой челлендж придет от проверяющей (от Google). Он знает, что это будет - прочитать какое-то 6-значное число и ввести его на клавиатуре. Требовать большего от живого человека было бы слишком жестоко.
Безопасная раскраска: специальная теория относительности, доказательство с нулевым разглашением и цветные графы