Arduino.ru

P.P.S. Общение ардуины и сервера через Seral не предлагать - не катит в моих условиях (первое сообщение не смог отредактировать - пришлось ещё одно написать).

Я успешно использую

* https://github.com/DavyLandman/AESLib

* http://excamera.com/sphinx/article-crc.html

Все помещается в atmega168 вместе с библиотекой rf24.

Кстати, нашел и DES: https://github.com/Octoate/ArduinoDES

toc, а как получаешь ответ от сервера?

Думается мне Ваша схема идеологически неверная. Обычно данные для открытия дверей хранят прямо на считывателе или его обвязке для того чтобы избежать проблем со связью. Ну а заканчивают данные на считыватель через сеть

Ну, это кому как. Также может и питание отключиться, ардуина повиснуть и еще много чего.

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

В любом случае, даже в вашей реализации, проблема передачи ключей по сети не снимается, посему и прошу помочь именно в решении данной проблемы - уж очень не хочется прибегать к "тяжелой артилерии", как то AES, DES, тем более медленной RSA и т.д.

А что толку шифровать посылку, если её перехватят, воспроизведут, отошлют и откроют дверь без всякой дешифрации

В сигнализациях применяют алгоритм, при котором каждая посылка относительно уникальная и уже принятые посылки не могут быть использованы повторно

Более подробно по этот алгоритм можно почитать тут (даташит на HCS301)

http://71reg.ru/hcs301.pdf

Сделайте список с одноразовыми ключами

Хм... С одноразовыми ключами тоже не вариант тогда. Ведь верно, если перехватить весь запрос и ещё раз его отправить, то отсылай ты просто шифрованный ключ или ключ и ключ для расшифровки или ключ и номер ключа в блокноте - не важно - сервер расшифрует и откроет двери.

Задумался...

CityCat, 

aes не "тяжёлая артилерия". Если не ошибаюсь, он аппаратно реализован в этих чипах. Библиотека AesLib - лишь обёртка для ардуины.

У меня нет сервера. Две дуины общаются по радио:

12 байт "полезной" нагрузки, в т.ч. результат millis(), и  4 байта - сумма crc32 c солью. Всё "защищаю" 16 байтным симметричным ключом с помощью aes128.

Примерно так и работает большинство сигнализаций.

Но принятый ключ блокируется в списке и второй раз не пройдет. А разблолкируется он только после некоторого количества принятых сообщений. Ссылку на описание алгоритма я уже давал. Но там сигнализации, радиосвязь, защита дорогостоящих машин от серьезных злоумышленников. Имеет смысл заморачиваться

Все таки проще использовать классический вариант - хранение данных о ID непосредственно в считывателе и закачка их туда через LAN, rs-485,wifi, bluetooth и тд и тп

Ключи можно не заново активировать, а с помощью второго массива новые получать.

Один массив с ключами, скажем 200 штук

Второй массив на обновление ключей еще 100 штук

Таким образом у нас будет 20к одноразовых ключей

Теперь еще больше запутался. Между 02h и 03h получаю 12 байт. Взглянул ещё раз в описание: 10ASCII Data Characters + Checksum. Теперь объясните мне - чексум же 1 байт? Откуда тогда 12-й? У меня, например одна метка выглядит как: "280016BB4ECB", другой как "3100B991263F". Кто пояснит, что за 12-й байт?

А зачем передаете millis()? Может чего почерпну для себя интересного... 

Не совсем понял данный алгоритм. Стало интересно. А можно поподробнее? Хотя, как мне кажется, не совсем вариант с массивами.

CityCat, я не понимаю о чём ты спрашиваешь. У меня нет такого rfid ридера. Вероятно, на твоём месте я бы сделал так:

в ардуине:

1. получил id метки от ридера (6 байт), начал собирать сообщение

2. запомнил текущее millis и приклеел его (4 байта) к сообщению

3. добавил на время в сообщение несколько фиксированных байт (соль)

4. вычислил сумму crc32, убрал соль

5. добавил сумму (4 байта) к сообщению

6. добавил два нулевых байта (нужно для аес)

7. имеем сообщение (16 байт). 

8. шифруем фиксированным 16-ти байтовым ключом, отправляем на сервер

на сервере:

9. расшифровываем тем же ключом

10. вычисляем сумму crc32 первых 10-ти байт с той же солью

11. сравниваем вычисленную сумму с полученной в сообщении (11-14 байты). Не совпадает - не отвечаем, иначе

12. проверяем по БД идентификатор метки, если можно пускать

13. собираем ответное сообщение

14. включаем в него "комманду открыть" и полученный ранее миллис плюс 1.

15. защищаем сообщение аналогичным образом (пп.3-8). Можно другие соль и ключ.

16. отправляем ардуине

на ардуине:

17. проверяем полученный ответ по аналогии (пп.9-11)

18. если получена "команда открыть" и ответ сервера содержит правильный миллис+1 открываем дверь.

.... при желании можно сообщить серверу "открыл".

По-моему, такой вариант достаточно устойчив к атаке типа man-in-the-middle.  Записанное и повторно отправленное злоумышленником сообщение не приведёт к открытию двери.

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

А что именно рассказать?
Есть rfid-считыватель, за ним стоит допустим, ардуина с эзернет-шилдом. Он отправляет запрос серверу (допустим, php) с номером карты. Скрипт сверяет его с присутствующем в БД и отправляет ответ открыть или нет дверь.
Ну, в постейшем случае, как-то так.

Теперь я не понял. А зачем шифровать вообще? Или у кого-то СПД и СКД в одну кучу свалены?