https://wirenboard.com/wiki/api.php?action=feedcontributions&user=Xenols&feedformat=atomWiren Board - Вклад [ru]2024-03-29T08:42:02ZВкладMediaWiki 1.37.0https://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17015CryptodevATECCx08 Auth2019-02-05T16:02:55Z<p>Xenols: /* Настройка mosquitto */</p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: '''nginx''', '''openssl''', '''mosquitto'''.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее командой:<br />
<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre><br />
<br />
Теперь приступим к созданию сертификатов.<br />
Для начала создадим свой центр сертификации (Certification Authority, '''CA'''):<br />
<br />
Для этого сгенерируем ключевую пару:<br />
<pre>openssl genrsa -out ca.key 2048</pre><br />
<br />
И сертификат нашего '''CA''':<br />
<br />
<pre>openssl req -x509 -new -days 3650 -key ca.key -out ca.crt -subj "/CN=MY CA"</pre><br />
<br />
'''CA''' является основой безопасности в данной схеме, поэтому эти операции выполняем на машине доступ к которой<br />
есть только у владельца '''CA'''.<br />
<br />
Далее на конроллере WB создаем запрос на сертификат устройства:<br />
<br />
<pre>openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device_AP6V5MDG.csr</pre><br />
<br />
В этой команде мы указываем, что запрос подписывается приватным ключом, находящимся в криптоустройстве ateccx08 ключом<br />
с идентификатором '''ATECCx08:00:04:C0:00''' и публичным именем wirenboard-AP6V5MDG. Запрос помещаем в файл device_AP6V5MDG.csr.<br />
<br />
Имя можно выбрать любое уникальное, удобно для этой цели спользовать идентификатор устройства, который по умолчанию прописывается<br />
в файле /etc/hostname:<br />
<br />
<pre><br />
cat /etc/hostname<br />
wirenboard-AP6V5MDG<br />
</pre><br />
<br />
Далее этот запрос подписываем в нашем центре сертификации:<br />
openssl x509 -req -in device_AP6V5MDG.csr -CA ca.crt -CAkey ca.key -out device_AP6V5MDG.crt -days 365 -CAcreateserial<br />
<br />
В этой команде мы уазываем файл запроса, и файлы CA необходимые для подписи. В итоге получаем сертификат устройства device_AP6V5MDG.crt.<br />
Файл '''device_AP6V5MDG.crt''' копируем на контроллер WB, он будет необходим для авторизацци.<br />
<br />
Давайте посмотрим, что содержится в файлах сертификатов CA и устройства:<br />
<br />
<pre><br />
openssl x509 -text -noout -in device_AP6V5MDG.crt<br />
<br />
Certificate:<br />
Data:<br />
Version: 1 (0x0)<br />
Serial Number:<br />
bf:85:29:be:19:67:f5:3e<br />
Signature Algorithm: sha256WithRSAEncryption<br />
Issuer: CN = MY CA<br />
Validity<br />
Not Before: Feb 4 14:50:14 2019 GMT<br />
Not After : Feb 4 14:50:14 2020 GMT<br />
Subject: CN = wirenboard-AP6V5MDG<br />
Subject Public Key Info:<br />
Public Key Algorithm: id-ecPublicKey<br />
Public-Key: (256 bit)<br />
pub:<br />
04:66:80:f6:83:ea:4f:88:a5:05:df:8f:2c:62:f3:<br />
ad:71:55:87:7f:ae:12:ae:b1:74:4b:68:68:fd:f7:<br />
e0:8a:f4:44:87:45:ab:c1:07:3f:54:2a:a9:ea:c6:<br />
71:1d:41:63:67:1b:75:f4:00:42:8d:fd:f6:d5:b6:<br />
52:38:e8:5a:a9<br />
ASN1 OID: prime256v1<br />
NIST CURVE: P-256<br />
Signature Algorithm: sha256WithRSAEncryption<br />
be:d1:f8:04:fb:34:a9:84:ff:25:b6:04:04:c0:f1:1d:4a:a4:<br />
04:b8:54:6c:a8:46:61:5f:6c:e7:ab:16:8f:ae:45:46:02:99:<br />
c6:d3:90:42:91:20:c7:89:d5:cf:4e:23:3a:33:64:ab:1b:c9:<br />
78:18:82:f4:39:8b:97:ae:6c:ee:a4:13:0c:5a:54:6b:69:c8:<br />
1e:fa:24:3d:48:2c:ea:0e:5c:0d:c3:43:c2:49:ea:b2:f8:5e:<br />
d7:0b:b5:4e:67:87:53:84:76:23:aa:10:77:5d:f1:21:9e:b0:<br />
4b:16:99:7c:d4:d3:d6:e7:00:9c:bf:53:a1:4b:f4:2c:fc:0b:<br />
64:10:fb:77:fc:3d:b2:71:cf:be:0b:b1:a2:62:ed:8c:92:e4:<br />
78:73:dc:69:c4:61:10:22:66:11:11:8b:d4:3c:b6:4f:7f:2c:<br />
24:07:61:47:15:2a:56:7e:71:69:59:15:8b:53:c8:e2:b5:ed:<br />
34:a0:78:70:d4:f6:cf:0f:6d:df:45:00:3b:0a:39:a2:fb:e7:<br />
89:f3:d9:88:7f:6b:bd:fa:ca:5e:44:94:74:70:5e:86:0b:93:<br />
ca:16:71:42:67:eb:77:bd:15:e3:90:2f:68:fd:bc:61:25:a3:<br />
a6:e7:8b:b1:42:bc:c2:36:d4:17:67:b3:77:fb:bd:06:e9:35:<br />
3b:8e:08:48<br />
</pre><br />
<br />
Видим, что сертификат выписан Центром сертификации с именем "MY CA" на 1 год, начная с "Feb 4 14:50:14 2019 GMT" (для этого мы указывали -days 365 в команде подписи),<br />
устройству с именем '''wirenboard-AP6V5MDG''', имеющим приватный ключ соответствующий публичному Subject Public Key Info.<br />
Сертификат подписан цифровой подписью. <br />
<br />
Цифровая подпись гарантирует, что никакая часть сертификата не может быть незаметно изменена. В случае изменения проверка публичным<br />
ключом '''CA''' даст ошибку.<br />
<br />
<pre><br />
openssl x509 -text -noout -in ca.crt<br />
<br />
Certificate:<br />
Data:<br />
Version: 3 (0x2)<br />
Serial Number:<br />
d9:e0:91:e7:d0:27:02:db<br />
Signature Algorithm: sha256WithRSAEncryption<br />
Issuer: CN = MY CA<br />
Validity<br />
Not Before: Feb 4 14:30:01 2019 GMT<br />
Not After : Feb 1 14:30:01 2029 GMT<br />
Subject: CN = MY CA<br />
Subject Public Key Info:<br />
Public Key Algorithm: rsaEncryption<br />
Public-Key: (2048 bit)<br />
Modulus:<br />
00:c8:5e:02:b8:55:e5:42:97:f7:c6:53:61:d3:df:<br />
66:bf:05:dd:7a:0c:61:a4:68:36:23:3f:3b:c7:83:<br />
ec:47:9b:5a:ed:78:8a:5b:f1:5f:88:3d:36:f2:3e:<br />
7b:84:9e:1b:e5:87:bf:3b:00:33:36:1c:0b:3a:16:<br />
2f:8d:be:0e:a4:9e:25:73:4d:93:8a:47:74:29:65:<br />
0e:4e:ea:44:fd:c4:c0:bf:fa:bc:11:d5:93:43:e2:<br />
65:18:bb:f7:e5:fc:16:8c:f9:11:97:76:2c:bb:cb:<br />
c0:94:7e:78:12:20:c9:8a:68:29:c1:e8:af:7e:d7:<br />
63:6e:a3:57:79:c9:b3:a8:8c:a3:2d:3e:15:1a:25:<br />
ea:f1:50:fc:ea:93:8f:14:5f:34:61:07:a9:dc:24:<br />
b8:11:de:9c:17:13:03:19:0d:0c:a3:e8:10:31:50:<br />
82:5b:cb:0e:26:d5:b1:fe:df:c3:f6:f9:e4:0f:b1:<br />
24:40:f2:8d:95:d5:ea:34:b3:27:a1:87:76:9d:f2:<br />
65:74:d5:40:47:dd:a1:32:46:c3:37:ec:a5:b3:09:<br />
30:73:99:d1:9c:bb:a8:05:61:2a:56:89:32:5e:c0:<br />
5d:1d:b6:a6:b6:74:17:be:74:69:9c:b0:e3:bc:b4:<br />
f9:96:6d:aa:60:ae:70:d1:ee:07:e5:2c:5d:0a:af:<br />
ce:b3<br />
Exponent: 65537 (0x10001)<br />
X509v3 extensions:<br />
X509v3 Subject Key Identifier: <br />
53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14<br />
X509v3 Authority Key Identifier: <br />
keyid:53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14<br />
<br />
X509v3 Basic Constraints: critical<br />
CA:TRUE<br />
Signature Algorithm: sha256WithRSAEncryption<br />
30:c2:f3:e0:96:51:7d:13:be:06:1d:40:06:70:b8:36:e9:46:<br />
81:64:0c:f0:e7:69:6f:31:2c:e1:86:df:f8:ad:b2:84:6e:90:<br />
4a:38:48:7d:ae:92:a5:71:40:c8:8e:0f:7e:67:e5:66:e7:70:<br />
4d:52:92:fa:a6:54:45:3b:a6:b9:b3:f4:35:ad:1c:6e:6e:15:<br />
06:81:ef:13:54:80:89:2e:7d:75:06:22:59:89:44:a9:ad:25:<br />
30:6c:02:e1:3b:2e:e2:bc:46:90:d1:a5:00:eb:87:57:60:a4:<br />
cf:e0:03:4a:b5:32:c4:dc:c7:e3:34:d4:c8:af:e3:ce:20:8c:<br />
c4:7f:f0:b8:72:d7:65:3b:38:be:2b:b1:d0:4e:9e:e2:52:32:<br />
41:fe:22:d2:7c:13:60:fe:4a:13:4b:c5:09:f0:00:89:32:22:<br />
47:4d:2c:a1:21:8e:b2:7d:0f:1a:10:f5:94:ee:fb:18:d3:15:<br />
f1:9e:70:89:73:c4:41:71:0e:92:22:9c:18:ef:0b:b1:7c:42:<br />
41:e7:9f:e7:82:d5:db:f3:60:d3:2f:2a:86:e4:0c:c0:4c:0c:<br />
17:12:ec:e4:37:96:dc:2d:01:00:22:ac:b5:33:6b:97:41:d7:<br />
37:e5:75:fa:c9:6b:00:2a:d8:87:0f:9e:f3:aa:c5:23:4e:60:<br />
02:a9:5b:eb<br />
</pre><br />
<br />
Видим, что сертификат подписан сам своим-же приватным ключом (Issuer: CN = MY CA, Subject: CN = MY CA)<br />
и выписан на 10 лет: начная с "Feb 4 14:30:01 2019 GMT" (для этого мы указывали -days 3650 в команде подписи)<br />
<br />
Таким образом цепочка доверия (проверки) выстраивается следующим образом:<br />
<br />
Сертификат устройства подписан сертификатом CA и может быть им проверен:<br />
<pre><br />
openssl verify -CAfile ca.crt device_AP6V5MDG.crt <br />
device_AP6V5MDG.crt: OK<br />
</pre><br />
<br />
Ну а сам сертификат подписан "собой":<br />
<pre><br />
openssl verify -CAfile ca.crt ca.crt<br />
ca.crt: OK<br />
</pre><br />
'''<br />
<br />
<br />
== Настройка nginx. ==<br />
<br />
Допустим в интернете есть сервер, который должен обрабатывать запросы только от устройств обладающих сертификатами,<br />
выписанными нашим CA.<br />
Для включения такой проверки в конфигурационном файле nginx необходимо в секции http или server прописать следующие строчки:<br />
<br />
<pre><br />
ssl_client_certificate ca.crt;<br />
ssl_verify_client on;<br />
</pre><br />
<br />
Теперь nginx будет требовать от клиента сертификат, который должен проходить проверку с помощью ca.crt, иначе сервер<br />
вернет клиенту ошибку 400:<br />
<br />
<pre><br />
curl https://example.com<br />
<html><br />
<head><title>400 No required SSL certificate was sent</title></head><br />
<body bgcolor="white"><br />
<center><h1>400 Bad Request</h1></center><br />
<center>No required SSL certificate was sent</center><br />
<hr><center>nginx/1.14.0 (Ubuntu)</center><br />
</body><br />
</html><br />
</pre><br />
<br />
Теперь сделаем так, чтобы HTTP запросы с контроллера WB проходили данную проверку.<br />
Для простоты будем использовать nginx и на клиентской стороне. Это даст возможность работать<br />
с защищенными серверами клиентам не умеющим делать SSL соединения.<br />
<br />
Для начала создадим на неиспользуемом локальном порту http сервер, который будет делать<br />
всю https "магию" за нас:<br />
<br />
<pre><br />
server {<br />
listen 8080;<br />
location / { <br />
proxy_pass https://example.com;<br />
proxy_ssl_name example.com;<br />
proxy_ssl_server_name on; <br />
proxy_ssl_certificate device_AP6V5MDG.crt;<br />
proxy_ssl_certificate_key engine:ateccx08:ATECCx08:00:04:C0:00;<br />
} <br />
}<br />
</pre><br />
<br />
Добавим пользователя www-data в группу i2c для доступа к криптоустройству:<br />
<pre><br />
usermod -G www-data<br />
</pre><br />
<br />
Выполним команду '''service nginx restart''' для обновления конфигурации.<br />
<br />
Теперь при обращении по http на локальный порт 8080 зашифрованные запросы с аутентификационной<br />
информацией будут отправлятся на сервер example.com.<br />
<br />
<pre><br />
curl localhost:8080/<br />
<html><br />
<body><br />
EXAMPLE.COM<br />
</body><br />
</html><br />
</pre><br />
<br />
== Настройка openvpn ==<br />
<br />
Для начала установим пакет:<br />
<br />
<pre><br />
apt install openvpn<br />
</pre><br />
<br />
Cоздадим файл req.cnf - он нам потребуется для создания сертификата сервера. <br />
<pre><br />
[ v3_req ]<br />
basicConstraints = CA:FALSE<br />
keyUsage = nonRepudiation, digitalSignature, keyEncipherment<br />
extendedKeyUsage = serverAuth, clientAuth<br />
</pre><br />
<br />
Серверу openvpn также требуется файл с параметрами DH, сделаем его.<br />
<pre><br />
openssl dhparam -out dh2048.pem 2048<br />
</pre><br />
<br />
Создание данного файла может потребовать несколько минут. <br />
<br />
Далее сделаем приватный ключ нашего сервера и запрос на сертификат. Предполагаем, для примера, что<br />
сервер имеет имя example.com:<br />
<br />
<pre> <br />
openssl genrsa -out example.key 2048<br />
<br />
openssl req -new -key example.key -subj "/CN=example.com" -out example.csr<br />
</pre><br />
<br />
Подписываем запрос в нашем центре сертификации:<br />
<br />
<pre><br />
openssl x509 -req -in example.csr -CA ca.crt -CAkey ca.key -out example.crt -days 365 -CAcreateserial -extfile req.cnf -extensions v3_req<br />
</pre><br />
<br />
Теперь приступим к настройке openvpn сервера на машине example.com.<br />
<br />
Копируем файлы '''ca.crt''', '''example.crt''', '''example.key''' и '''dh2048.pem''' и редактируем файл конфигурации openvpn сервера.<br />
По умолчанию конфигурационный файл лежит в файле /etc/openvpn/server.conf<br />
<br />
<pre><br />
port 1194<br />
proto tcp <br />
dev tun <br />
ca /etc/openvpn/server/ca.crt<br />
cert /etc/openvpn/server/example.crt<br />
key /etc/openvpn/server/example.key<br />
dh /etc/openvpn/server/dh2048.pem<br />
topology subnet<br />
server 10.8.0.0 255.255.255.0<br />
keepalive 10 60<br />
key-direction 0<br />
cipher AES-128-CBC<br />
auth SHA256<br />
comp-lzo<br />
user nobody<br />
group nogroup<br />
persist-key<br />
persist-tun<br />
status /var/run/openvpn/openvpn-status.log<br />
management 127.0.0.1 7500<br />
log-append /var/log/openvpn.log<br />
</pre><br />
<br />
Добавим пользователя openvpn в группу i2c для доступа к криптоустройству:<br />
<br />
<pre><br />
usermod -G www-data<br />
</pre><br />
<br />
после этого запускаем сервер командой <br />
service openvpn start.<br />
<br />
Далее на контроллере создаем файл конфигурации клиента:<br />
client.ovpn:<br />
-------------------------------------------------------------------------<br />
client<br />
dev tun<br />
proto tcp<br />
remote example.com 1194<br />
resolv-retry infinite<br />
nobind<br />
user openvpn<br />
'''group i2c'''<br />
persist-key<br />
persist-tun<br />
cipher AES-128-CBC<br />
auth SHA256<br />
key-direction 1<br />
keepalive 1 10<br />
remote-cert-tls server<br />
comp-lzo<br />
-------------------------------------------------------------------------<br />
<br />
Обратите внимание на строчку group i2c. Она необходима для работы с криптоустройством.<br />
<br />
После этого запускаем клиента:<br />
<br />
<pre><br />
openvpn --config example.ovpn --ca ca.crt --cert device_AP6V5MDG.crt --key engine:ateccx08:ATECCx08:00:04:C0:00<br />
</pre><br />
<br />
Если все хорошо, то в системе должен появиться интерфейс tun0 с адресом из подсети 10.8.0.0/24:<br />
<br />
<pre><br />
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500<br />
inet 10.8.0.2 netmask 255.255.255.0 destination 10.8.0.2<br />
inet6 fe80::53b0:83f3:b1f5:b817 prefixlen 64 scopeid 0x20<link><br />
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)<br />
RX packets 0 bytes 0 (0.0 B)<br />
RX errors 0 dropped 0 overruns 0 frame 0<br />
TX packets 6 bytes 288 (288.0 B)<br />
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0<br />
</pre><br />
<br />
Для проверки работоспособности запускаем ping:<br />
<br />
<pre><br />
ping 10.8.0.1<br />
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.<br />
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=2.23 ms<br />
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=2.83 ms<br />
</pre><br />
<br />
== Настройка mosquitto ==<br />
<br />
Генерируем приватный ключ и запрос на сертификат:<br />
<br />
<pre><br />
openssl genrsa -out example.key 2048<br />
openssl req -new -key example.key -subj "/CN=example.com" -out example.csr<br />
</pre><br />
<br />
Создаем сертификат сервера в CA.<br />
<pre><br />
openssl x509 -req -in example.csr -CA ca.crt -CAkey ca.key -out example.crt -days 365 -CAcreateserial -extfile req.cnf -extensions v3_req<br />
</pre><br />
<br />
Копируем файлы '''ca.crt''', '''mosquitto.crt''', '''mosquitto.key''' на сервер и редактируем файл конфигурации '''/etc/mosquitto/conf.d/server.conf'''<br />
<br />
<pre><br />
cafile /etc/mosquitto/ssl/ca.crt<br />
certfile /etc/mosquitto/ssl/mosquitto.crt<br />
keyfile /etc/mosquitto/ssl/mosquitto.key<br />
require_certificate true<br />
use_identity_as_username true<br />
</pre><br />
<br />
Запускаем серис:<br />
<pre><br />
service mosquitto start<br />
</pre><br />
<br />
Также, если требуется, можно сделать чтобы локальный mosquitto сервер на контроллере<br />
форвардил некоторые топики на удаленный сервер. Для этого создаем файл бриджа: '''/etc/mosquitto/bridge.conf'''<br />
<br />
<pre><br />
connection main<br />
topic test/# out<br />
address example.com:1883<br />
<br />
bridge_cafile /etc/mosquitto/certs/ca.crt<br />
bridge_certfile /etc/mosquitto/certs/device_AP6V5MDG.crt<br />
bridge_keyfile engine:ateccx08:ATECCx08:00:04:C0:00<br />
</pre><br />
<br />
После перезапуска локального сервиса mosquitto топики /test/.. будут отправлятся на удаленный сервер example.com<br />
по защищенному ssl каналу.<br />
<br />
Примеры клиентских команд mosquitto.<br />
Отправка сообщения "message" в топик "test" на сервере example.com <br />
<br />
<pre><br />
mosquitto_pub -h example.com --cert device_AP6V5MDG.crt --key 'engine:ateccx08:ATECCx08:00:04:C0:00' --cafile ca.crt -t "test" -m "message" <br />
</pre><br />
<br />
Получение сообщений из топика "test" на сервере example.com<br />
<br />
<pre><br />
mosquitto_sub -h example.com --cert device_AP6V5MDG.crt --key 'engine:ateccx08:ATECCx08:00:04:C0:00' -t "test" --cafile ca.crt<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17014CryptodevATECCx08 Auth2019-02-05T16:02:03Z<p>Xenols: /* Настройка mosquitto */</p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: '''nginx''', '''openssl''', '''mosquitto'''.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее командой:<br />
<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre><br />
<br />
Теперь приступим к созданию сертификатов.<br />
Для начала создадим свой центр сертификации (Certification Authority, '''CA'''):<br />
<br />
Для этого сгенерируем ключевую пару:<br />
<pre>openssl genrsa -out ca.key 2048</pre><br />
<br />
И сертификат нашего '''CA''':<br />
<br />
<pre>openssl req -x509 -new -days 3650 -key ca.key -out ca.crt -subj "/CN=MY CA"</pre><br />
<br />
'''CA''' является основой безопасности в данной схеме, поэтому эти операции выполняем на машине доступ к которой<br />
есть только у владельца '''CA'''.<br />
<br />
Далее на конроллере WB создаем запрос на сертификат устройства:<br />
<br />
<pre>openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device_AP6V5MDG.csr</pre><br />
<br />
В этой команде мы указываем, что запрос подписывается приватным ключом, находящимся в криптоустройстве ateccx08 ключом<br />
с идентификатором '''ATECCx08:00:04:C0:00''' и публичным именем wirenboard-AP6V5MDG. Запрос помещаем в файл device_AP6V5MDG.csr.<br />
<br />
Имя можно выбрать любое уникальное, удобно для этой цели спользовать идентификатор устройства, который по умолчанию прописывается<br />
в файле /etc/hostname:<br />
<br />
<pre><br />
cat /etc/hostname<br />
wirenboard-AP6V5MDG<br />
</pre><br />
<br />
Далее этот запрос подписываем в нашем центре сертификации:<br />
openssl x509 -req -in device_AP6V5MDG.csr -CA ca.crt -CAkey ca.key -out device_AP6V5MDG.crt -days 365 -CAcreateserial<br />
<br />
В этой команде мы уазываем файл запроса, и файлы CA необходимые для подписи. В итоге получаем сертификат устройства device_AP6V5MDG.crt.<br />
Файл '''device_AP6V5MDG.crt''' копируем на контроллер WB, он будет необходим для авторизацци.<br />
<br />
Давайте посмотрим, что содержится в файлах сертификатов CA и устройства:<br />
<br />
<pre><br />
openssl x509 -text -noout -in device_AP6V5MDG.crt<br />
<br />
Certificate:<br />
Data:<br />
Version: 1 (0x0)<br />
Serial Number:<br />
bf:85:29:be:19:67:f5:3e<br />
Signature Algorithm: sha256WithRSAEncryption<br />
Issuer: CN = MY CA<br />
Validity<br />
Not Before: Feb 4 14:50:14 2019 GMT<br />
Not After : Feb 4 14:50:14 2020 GMT<br />
Subject: CN = wirenboard-AP6V5MDG<br />
Subject Public Key Info:<br />
Public Key Algorithm: id-ecPublicKey<br />
Public-Key: (256 bit)<br />
pub:<br />
04:66:80:f6:83:ea:4f:88:a5:05:df:8f:2c:62:f3:<br />
ad:71:55:87:7f:ae:12:ae:b1:74:4b:68:68:fd:f7:<br />
e0:8a:f4:44:87:45:ab:c1:07:3f:54:2a:a9:ea:c6:<br />
71:1d:41:63:67:1b:75:f4:00:42:8d:fd:f6:d5:b6:<br />
52:38:e8:5a:a9<br />
ASN1 OID: prime256v1<br />
NIST CURVE: P-256<br />
Signature Algorithm: sha256WithRSAEncryption<br />
be:d1:f8:04:fb:34:a9:84:ff:25:b6:04:04:c0:f1:1d:4a:a4:<br />
04:b8:54:6c:a8:46:61:5f:6c:e7:ab:16:8f:ae:45:46:02:99:<br />
c6:d3:90:42:91:20:c7:89:d5:cf:4e:23:3a:33:64:ab:1b:c9:<br />
78:18:82:f4:39:8b:97:ae:6c:ee:a4:13:0c:5a:54:6b:69:c8:<br />
1e:fa:24:3d:48:2c:ea:0e:5c:0d:c3:43:c2:49:ea:b2:f8:5e:<br />
d7:0b:b5:4e:67:87:53:84:76:23:aa:10:77:5d:f1:21:9e:b0:<br />
4b:16:99:7c:d4:d3:d6:e7:00:9c:bf:53:a1:4b:f4:2c:fc:0b:<br />
64:10:fb:77:fc:3d:b2:71:cf:be:0b:b1:a2:62:ed:8c:92:e4:<br />
78:73:dc:69:c4:61:10:22:66:11:11:8b:d4:3c:b6:4f:7f:2c:<br />
24:07:61:47:15:2a:56:7e:71:69:59:15:8b:53:c8:e2:b5:ed:<br />
34:a0:78:70:d4:f6:cf:0f:6d:df:45:00:3b:0a:39:a2:fb:e7:<br />
89:f3:d9:88:7f:6b:bd:fa:ca:5e:44:94:74:70:5e:86:0b:93:<br />
ca:16:71:42:67:eb:77:bd:15:e3:90:2f:68:fd:bc:61:25:a3:<br />
a6:e7:8b:b1:42:bc:c2:36:d4:17:67:b3:77:fb:bd:06:e9:35:<br />
3b:8e:08:48<br />
</pre><br />
<br />
Видим, что сертификат выписан Центром сертификации с именем "MY CA" на 1 год, начная с "Feb 4 14:50:14 2019 GMT" (для этого мы указывали -days 365 в команде подписи),<br />
устройству с именем '''wirenboard-AP6V5MDG''', имеющим приватный ключ соответствующий публичному Subject Public Key Info.<br />
Сертификат подписан цифровой подписью. <br />
<br />
Цифровая подпись гарантирует, что никакая часть сертификата не может быть незаметно изменена. В случае изменения проверка публичным<br />
ключом '''CA''' даст ошибку.<br />
<br />
<pre><br />
openssl x509 -text -noout -in ca.crt<br />
<br />
Certificate:<br />
Data:<br />
Version: 3 (0x2)<br />
Serial Number:<br />
d9:e0:91:e7:d0:27:02:db<br />
Signature Algorithm: sha256WithRSAEncryption<br />
Issuer: CN = MY CA<br />
Validity<br />
Not Before: Feb 4 14:30:01 2019 GMT<br />
Not After : Feb 1 14:30:01 2029 GMT<br />
Subject: CN = MY CA<br />
Subject Public Key Info:<br />
Public Key Algorithm: rsaEncryption<br />
Public-Key: (2048 bit)<br />
Modulus:<br />
00:c8:5e:02:b8:55:e5:42:97:f7:c6:53:61:d3:df:<br />
66:bf:05:dd:7a:0c:61:a4:68:36:23:3f:3b:c7:83:<br />
ec:47:9b:5a:ed:78:8a:5b:f1:5f:88:3d:36:f2:3e:<br />
7b:84:9e:1b:e5:87:bf:3b:00:33:36:1c:0b:3a:16:<br />
2f:8d:be:0e:a4:9e:25:73:4d:93:8a:47:74:29:65:<br />
0e:4e:ea:44:fd:c4:c0:bf:fa:bc:11:d5:93:43:e2:<br />
65:18:bb:f7:e5:fc:16:8c:f9:11:97:76:2c:bb:cb:<br />
c0:94:7e:78:12:20:c9:8a:68:29:c1:e8:af:7e:d7:<br />
63:6e:a3:57:79:c9:b3:a8:8c:a3:2d:3e:15:1a:25:<br />
ea:f1:50:fc:ea:93:8f:14:5f:34:61:07:a9:dc:24:<br />
b8:11:de:9c:17:13:03:19:0d:0c:a3:e8:10:31:50:<br />
82:5b:cb:0e:26:d5:b1:fe:df:c3:f6:f9:e4:0f:b1:<br />
24:40:f2:8d:95:d5:ea:34:b3:27:a1:87:76:9d:f2:<br />
65:74:d5:40:47:dd:a1:32:46:c3:37:ec:a5:b3:09:<br />
30:73:99:d1:9c:bb:a8:05:61:2a:56:89:32:5e:c0:<br />
5d:1d:b6:a6:b6:74:17:be:74:69:9c:b0:e3:bc:b4:<br />
f9:96:6d:aa:60:ae:70:d1:ee:07:e5:2c:5d:0a:af:<br />
ce:b3<br />
Exponent: 65537 (0x10001)<br />
X509v3 extensions:<br />
X509v3 Subject Key Identifier: <br />
53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14<br />
X509v3 Authority Key Identifier: <br />
keyid:53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14<br />
<br />
X509v3 Basic Constraints: critical<br />
CA:TRUE<br />
Signature Algorithm: sha256WithRSAEncryption<br />
30:c2:f3:e0:96:51:7d:13:be:06:1d:40:06:70:b8:36:e9:46:<br />
81:64:0c:f0:e7:69:6f:31:2c:e1:86:df:f8:ad:b2:84:6e:90:<br />
4a:38:48:7d:ae:92:a5:71:40:c8:8e:0f:7e:67:e5:66:e7:70:<br />
4d:52:92:fa:a6:54:45:3b:a6:b9:b3:f4:35:ad:1c:6e:6e:15:<br />
06:81:ef:13:54:80:89:2e:7d:75:06:22:59:89:44:a9:ad:25:<br />
30:6c:02:e1:3b:2e:e2:bc:46:90:d1:a5:00:eb:87:57:60:a4:<br />
cf:e0:03:4a:b5:32:c4:dc:c7:e3:34:d4:c8:af:e3:ce:20:8c:<br />
c4:7f:f0:b8:72:d7:65:3b:38:be:2b:b1:d0:4e:9e:e2:52:32:<br />
41:fe:22:d2:7c:13:60:fe:4a:13:4b:c5:09:f0:00:89:32:22:<br />
47:4d:2c:a1:21:8e:b2:7d:0f:1a:10:f5:94:ee:fb:18:d3:15:<br />
f1:9e:70:89:73:c4:41:71:0e:92:22:9c:18:ef:0b:b1:7c:42:<br />
41:e7:9f:e7:82:d5:db:f3:60:d3:2f:2a:86:e4:0c:c0:4c:0c:<br />
17:12:ec:e4:37:96:dc:2d:01:00:22:ac:b5:33:6b:97:41:d7:<br />
37:e5:75:fa:c9:6b:00:2a:d8:87:0f:9e:f3:aa:c5:23:4e:60:<br />
02:a9:5b:eb<br />
</pre><br />
<br />
Видим, что сертификат подписан сам своим-же приватным ключом (Issuer: CN = MY CA, Subject: CN = MY CA)<br />
и выписан на 10 лет: начная с "Feb 4 14:30:01 2019 GMT" (для этого мы указывали -days 3650 в команде подписи)<br />
<br />
Таким образом цепочка доверия (проверки) выстраивается следующим образом:<br />
<br />
Сертификат устройства подписан сертификатом CA и может быть им проверен:<br />
<pre><br />
openssl verify -CAfile ca.crt device_AP6V5MDG.crt <br />
device_AP6V5MDG.crt: OK<br />
</pre><br />
<br />
Ну а сам сертификат подписан "собой":<br />
<pre><br />
openssl verify -CAfile ca.crt ca.crt<br />
ca.crt: OK<br />
</pre><br />
'''<br />
<br />
<br />
== Настройка nginx. ==<br />
<br />
Допустим в интернете есть сервер, который должен обрабатывать запросы только от устройств обладающих сертификатами,<br />
выписанными нашим CA.<br />
Для включения такой проверки в конфигурационном файле nginx необходимо в секции http или server прописать следующие строчки:<br />
<br />
<pre><br />
ssl_client_certificate ca.crt;<br />
ssl_verify_client on;<br />
</pre><br />
<br />
Теперь nginx будет требовать от клиента сертификат, который должен проходить проверку с помощью ca.crt, иначе сервер<br />
вернет клиенту ошибку 400:<br />
<br />
<pre><br />
curl https://example.com<br />
<html><br />
<head><title>400 No required SSL certificate was sent</title></head><br />
<body bgcolor="white"><br />
<center><h1>400 Bad Request</h1></center><br />
<center>No required SSL certificate was sent</center><br />
<hr><center>nginx/1.14.0 (Ubuntu)</center><br />
</body><br />
</html><br />
</pre><br />
<br />
Теперь сделаем так, чтобы HTTP запросы с контроллера WB проходили данную проверку.<br />
Для простоты будем использовать nginx и на клиентской стороне. Это даст возможность работать<br />
с защищенными серверами клиентам не умеющим делать SSL соединения.<br />
<br />
Для начала создадим на неиспользуемом локальном порту http сервер, который будет делать<br />
всю https "магию" за нас:<br />
<br />
<pre><br />
server {<br />
listen 8080;<br />
location / { <br />
proxy_pass https://example.com;<br />
proxy_ssl_name example.com;<br />
proxy_ssl_server_name on; <br />
proxy_ssl_certificate device_AP6V5MDG.crt;<br />
proxy_ssl_certificate_key engine:ateccx08:ATECCx08:00:04:C0:00;<br />
} <br />
}<br />
</pre><br />
<br />
Добавим пользователя www-data в группу i2c для доступа к криптоустройству:<br />
<pre><br />
usermod -G www-data<br />
</pre><br />
<br />
Выполним команду '''service nginx restart''' для обновления конфигурации.<br />
<br />
Теперь при обращении по http на локальный порт 8080 зашифрованные запросы с аутентификационной<br />
информацией будут отправлятся на сервер example.com.<br />
<br />
<pre><br />
curl localhost:8080/<br />
<html><br />
<body><br />
EXAMPLE.COM<br />
</body><br />
</html><br />
</pre><br />
<br />
== Настройка openvpn ==<br />
<br />
Для начала установим пакет:<br />
<br />
<pre><br />
apt install openvpn<br />
</pre><br />
<br />
Cоздадим файл req.cnf - он нам потребуется для создания сертификата сервера. <br />
<pre><br />
[ v3_req ]<br />
basicConstraints = CA:FALSE<br />
keyUsage = nonRepudiation, digitalSignature, keyEncipherment<br />
extendedKeyUsage = serverAuth, clientAuth<br />
</pre><br />
<br />
Серверу openvpn также требуется файл с параметрами DH, сделаем его.<br />
<pre><br />
openssl dhparam -out dh2048.pem 2048<br />
</pre><br />
<br />
Создание данного файла может потребовать несколько минут. <br />
<br />
Далее сделаем приватный ключ нашего сервера и запрос на сертификат. Предполагаем, для примера, что<br />
сервер имеет имя example.com:<br />
<br />
<pre> <br />
openssl genrsa -out example.key 2048<br />
<br />
openssl req -new -key example.key -subj "/CN=example.com" -out example.csr<br />
</pre><br />
<br />
Подписываем запрос в нашем центре сертификации:<br />
<br />
<pre><br />
openssl x509 -req -in example.csr -CA ca.crt -CAkey ca.key -out example.crt -days 365 -CAcreateserial -extfile req.cnf -extensions v3_req<br />
</pre><br />
<br />
Теперь приступим к настройке openvpn сервера на машине example.com.<br />
<br />
Копируем файлы '''ca.crt''', '''example.crt''', '''example.key''' и '''dh2048.pem''' и редактируем файл конфигурации openvpn сервера.<br />
По умолчанию конфигурационный файл лежит в файле /etc/openvpn/server.conf<br />
<br />
<pre><br />
port 1194<br />
proto tcp <br />
dev tun <br />
ca /etc/openvpn/server/ca.crt<br />
cert /etc/openvpn/server/example.crt<br />
key /etc/openvpn/server/example.key<br />
dh /etc/openvpn/server/dh2048.pem<br />
topology subnet<br />
server 10.8.0.0 255.255.255.0<br />
keepalive 10 60<br />
key-direction 0<br />
cipher AES-128-CBC<br />
auth SHA256<br />
comp-lzo<br />
user nobody<br />
group nogroup<br />
persist-key<br />
persist-tun<br />
status /var/run/openvpn/openvpn-status.log<br />
management 127.0.0.1 7500<br />
log-append /var/log/openvpn.log<br />
</pre><br />
<br />
Добавим пользователя openvpn в группу i2c для доступа к криптоустройству:<br />
<br />
<pre><br />
usermod -G www-data<br />
</pre><br />
<br />
после этого запускаем сервер командой <br />
service openvpn start.<br />
<br />
Далее на контроллере создаем файл конфигурации клиента:<br />
client.ovpn:<br />
-------------------------------------------------------------------------<br />
client<br />
dev tun<br />
proto tcp<br />
remote example.com 1194<br />
resolv-retry infinite<br />
nobind<br />
user openvpn<br />
'''group i2c'''<br />
persist-key<br />
persist-tun<br />
cipher AES-128-CBC<br />
auth SHA256<br />
key-direction 1<br />
keepalive 1 10<br />
remote-cert-tls server<br />
comp-lzo<br />
-------------------------------------------------------------------------<br />
<br />
Обратите внимание на строчку group i2c. Она необходима для работы с криптоустройством.<br />
<br />
После этого запускаем клиента:<br />
<br />
<pre><br />
openvpn --config example.ovpn --ca ca.crt --cert device_AP6V5MDG.crt --key engine:ateccx08:ATECCx08:00:04:C0:00<br />
</pre><br />
<br />
Если все хорошо, то в системе должен появиться интерфейс tun0 с адресом из подсети 10.8.0.0/24:<br />
<br />
<pre><br />
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500<br />
inet 10.8.0.2 netmask 255.255.255.0 destination 10.8.0.2<br />
inet6 fe80::53b0:83f3:b1f5:b817 prefixlen 64 scopeid 0x20<link><br />
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)<br />
RX packets 0 bytes 0 (0.0 B)<br />
RX errors 0 dropped 0 overruns 0 frame 0<br />
TX packets 6 bytes 288 (288.0 B)<br />
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0<br />
</pre><br />
<br />
Для проверки работоспособности запускаем ping:<br />
<br />
<pre><br />
ping 10.8.0.1<br />
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.<br />
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=2.23 ms<br />
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=2.83 ms<br />
</pre><br />
<br />
== Настройка mosquitto ==<br />
<br />
Генерируем приватный ключ и запрос на сертификат:<br />
<br />
<pre><br />
openssl genrsa -out example.key 2048<br />
openssl req -new -key example.key -subj "/CN=example.com" -out example.csr<br />
</pre><br />
<br />
Создаем сертификат сервера в CA.<br />
<pre><br />
openssl x509 -req -in example.csr -CA ca.crt -CAkey ca.key -out example.crt -days 365 -CAcreateserial -extfile req.cnf -extensions v3_req<br />
</pre><br />
<br />
Копируем файлы '''ca.crt''', '''mosquitto.crt''', '''mosquitto.key''' на сервер и редактируем файл конфигурации:<br />
<br />
/etc/mosquitto/conf.d/server.conf<br />
<br />
<pre><br />
cafile /etc/mosquitto/ssl/ca.crt<br />
certfile /etc/mosquitto/ssl/mosquitto.crt<br />
keyfile /etc/mosquitto/ssl/mosquitto.key<br />
require_certificate true<br />
use_identity_as_username true<br />
</pre><br />
<br />
Запускаем серис:<br />
<pre><br />
service mosquitto start<br />
</pre><br />
<br />
Также, если требуется, можно сделать чтобы локальный mosquitto сервер на контроллере<br />
форвардил некоторые топики на удаленный сервер. Для этого создаем файл бриджа: '''/etc/mosquitto/bridge.conf'''<br />
<br />
<pre><br />
connection main<br />
topic test/# out<br />
address example.com:1883<br />
<br />
bridge_cafile /etc/mosquitto/certs/ca.crt<br />
bridge_certfile /etc/mosquitto/certs/device_AP6V5MDG.crt<br />
bridge_keyfile engine:ateccx08:ATECCx08:00:04:C0:00<br />
</pre><br />
<br />
После перезапуска локального сервиса mosquitto топики /test/.. будут отправлятся на удаленный сервер example.com<br />
по защищенному ssl каналу.<br />
<br />
Примеры клиентских команд mosquitto.<br />
Отправка сообщения "message" в топик "test" на сервере example.com <br />
<br />
<pre><br />
mosquitto_pub -h example.com --cert device_AP6V5MDG.crt --key 'engine:ateccx08:ATECCx08:00:04:C0:00' --cafile ca.crt -t "test" -m "message" <br />
</pre><br />
<br />
Получение сообщений из топика "test" на сервере example.com<br />
<br />
<pre><br />
mosquitto_sub -h example.com --cert device_AP6V5MDG.crt --key 'engine:ateccx08:ATECCx08:00:04:C0:00' -t "test" --cafile ca.crt<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17013CryptodevATECCx08 Auth2019-02-05T16:01:19Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: '''nginx''', '''openssl''', '''mosquitto'''.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее командой:<br />
<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre><br />
<br />
Теперь приступим к созданию сертификатов.<br />
Для начала создадим свой центр сертификации (Certification Authority, '''CA'''):<br />
<br />
Для этого сгенерируем ключевую пару:<br />
<pre>openssl genrsa -out ca.key 2048</pre><br />
<br />
И сертификат нашего '''CA''':<br />
<br />
<pre>openssl req -x509 -new -days 3650 -key ca.key -out ca.crt -subj "/CN=MY CA"</pre><br />
<br />
'''CA''' является основой безопасности в данной схеме, поэтому эти операции выполняем на машине доступ к которой<br />
есть только у владельца '''CA'''.<br />
<br />
Далее на конроллере WB создаем запрос на сертификат устройства:<br />
<br />
<pre>openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device_AP6V5MDG.csr</pre><br />
<br />
В этой команде мы указываем, что запрос подписывается приватным ключом, находящимся в криптоустройстве ateccx08 ключом<br />
с идентификатором '''ATECCx08:00:04:C0:00''' и публичным именем wirenboard-AP6V5MDG. Запрос помещаем в файл device_AP6V5MDG.csr.<br />
<br />
Имя можно выбрать любое уникальное, удобно для этой цели спользовать идентификатор устройства, который по умолчанию прописывается<br />
в файле /etc/hostname:<br />
<br />
<pre><br />
cat /etc/hostname<br />
wirenboard-AP6V5MDG<br />
</pre><br />
<br />
Далее этот запрос подписываем в нашем центре сертификации:<br />
openssl x509 -req -in device_AP6V5MDG.csr -CA ca.crt -CAkey ca.key -out device_AP6V5MDG.crt -days 365 -CAcreateserial<br />
<br />
В этой команде мы уазываем файл запроса, и файлы CA необходимые для подписи. В итоге получаем сертификат устройства device_AP6V5MDG.crt.<br />
Файл '''device_AP6V5MDG.crt''' копируем на контроллер WB, он будет необходим для авторизацци.<br />
<br />
Давайте посмотрим, что содержится в файлах сертификатов CA и устройства:<br />
<br />
<pre><br />
openssl x509 -text -noout -in device_AP6V5MDG.crt<br />
<br />
Certificate:<br />
Data:<br />
Version: 1 (0x0)<br />
Serial Number:<br />
bf:85:29:be:19:67:f5:3e<br />
Signature Algorithm: sha256WithRSAEncryption<br />
Issuer: CN = MY CA<br />
Validity<br />
Not Before: Feb 4 14:50:14 2019 GMT<br />
Not After : Feb 4 14:50:14 2020 GMT<br />
Subject: CN = wirenboard-AP6V5MDG<br />
Subject Public Key Info:<br />
Public Key Algorithm: id-ecPublicKey<br />
Public-Key: (256 bit)<br />
pub:<br />
04:66:80:f6:83:ea:4f:88:a5:05:df:8f:2c:62:f3:<br />
ad:71:55:87:7f:ae:12:ae:b1:74:4b:68:68:fd:f7:<br />
e0:8a:f4:44:87:45:ab:c1:07:3f:54:2a:a9:ea:c6:<br />
71:1d:41:63:67:1b:75:f4:00:42:8d:fd:f6:d5:b6:<br />
52:38:e8:5a:a9<br />
ASN1 OID: prime256v1<br />
NIST CURVE: P-256<br />
Signature Algorithm: sha256WithRSAEncryption<br />
be:d1:f8:04:fb:34:a9:84:ff:25:b6:04:04:c0:f1:1d:4a:a4:<br />
04:b8:54:6c:a8:46:61:5f:6c:e7:ab:16:8f:ae:45:46:02:99:<br />
c6:d3:90:42:91:20:c7:89:d5:cf:4e:23:3a:33:64:ab:1b:c9:<br />
78:18:82:f4:39:8b:97:ae:6c:ee:a4:13:0c:5a:54:6b:69:c8:<br />
1e:fa:24:3d:48:2c:ea:0e:5c:0d:c3:43:c2:49:ea:b2:f8:5e:<br />
d7:0b:b5:4e:67:87:53:84:76:23:aa:10:77:5d:f1:21:9e:b0:<br />
4b:16:99:7c:d4:d3:d6:e7:00:9c:bf:53:a1:4b:f4:2c:fc:0b:<br />
64:10:fb:77:fc:3d:b2:71:cf:be:0b:b1:a2:62:ed:8c:92:e4:<br />
78:73:dc:69:c4:61:10:22:66:11:11:8b:d4:3c:b6:4f:7f:2c:<br />
24:07:61:47:15:2a:56:7e:71:69:59:15:8b:53:c8:e2:b5:ed:<br />
34:a0:78:70:d4:f6:cf:0f:6d:df:45:00:3b:0a:39:a2:fb:e7:<br />
89:f3:d9:88:7f:6b:bd:fa:ca:5e:44:94:74:70:5e:86:0b:93:<br />
ca:16:71:42:67:eb:77:bd:15:e3:90:2f:68:fd:bc:61:25:a3:<br />
a6:e7:8b:b1:42:bc:c2:36:d4:17:67:b3:77:fb:bd:06:e9:35:<br />
3b:8e:08:48<br />
</pre><br />
<br />
Видим, что сертификат выписан Центром сертификации с именем "MY CA" на 1 год, начная с "Feb 4 14:50:14 2019 GMT" (для этого мы указывали -days 365 в команде подписи),<br />
устройству с именем '''wirenboard-AP6V5MDG''', имеющим приватный ключ соответствующий публичному Subject Public Key Info.<br />
Сертификат подписан цифровой подписью. <br />
<br />
Цифровая подпись гарантирует, что никакая часть сертификата не может быть незаметно изменена. В случае изменения проверка публичным<br />
ключом '''CA''' даст ошибку.<br />
<br />
<pre><br />
openssl x509 -text -noout -in ca.crt<br />
<br />
Certificate:<br />
Data:<br />
Version: 3 (0x2)<br />
Serial Number:<br />
d9:e0:91:e7:d0:27:02:db<br />
Signature Algorithm: sha256WithRSAEncryption<br />
Issuer: CN = MY CA<br />
Validity<br />
Not Before: Feb 4 14:30:01 2019 GMT<br />
Not After : Feb 1 14:30:01 2029 GMT<br />
Subject: CN = MY CA<br />
Subject Public Key Info:<br />
Public Key Algorithm: rsaEncryption<br />
Public-Key: (2048 bit)<br />
Modulus:<br />
00:c8:5e:02:b8:55:e5:42:97:f7:c6:53:61:d3:df:<br />
66:bf:05:dd:7a:0c:61:a4:68:36:23:3f:3b:c7:83:<br />
ec:47:9b:5a:ed:78:8a:5b:f1:5f:88:3d:36:f2:3e:<br />
7b:84:9e:1b:e5:87:bf:3b:00:33:36:1c:0b:3a:16:<br />
2f:8d:be:0e:a4:9e:25:73:4d:93:8a:47:74:29:65:<br />
0e:4e:ea:44:fd:c4:c0:bf:fa:bc:11:d5:93:43:e2:<br />
65:18:bb:f7:e5:fc:16:8c:f9:11:97:76:2c:bb:cb:<br />
c0:94:7e:78:12:20:c9:8a:68:29:c1:e8:af:7e:d7:<br />
63:6e:a3:57:79:c9:b3:a8:8c:a3:2d:3e:15:1a:25:<br />
ea:f1:50:fc:ea:93:8f:14:5f:34:61:07:a9:dc:24:<br />
b8:11:de:9c:17:13:03:19:0d:0c:a3:e8:10:31:50:<br />
82:5b:cb:0e:26:d5:b1:fe:df:c3:f6:f9:e4:0f:b1:<br />
24:40:f2:8d:95:d5:ea:34:b3:27:a1:87:76:9d:f2:<br />
65:74:d5:40:47:dd:a1:32:46:c3:37:ec:a5:b3:09:<br />
30:73:99:d1:9c:bb:a8:05:61:2a:56:89:32:5e:c0:<br />
5d:1d:b6:a6:b6:74:17:be:74:69:9c:b0:e3:bc:b4:<br />
f9:96:6d:aa:60:ae:70:d1:ee:07:e5:2c:5d:0a:af:<br />
ce:b3<br />
Exponent: 65537 (0x10001)<br />
X509v3 extensions:<br />
X509v3 Subject Key Identifier: <br />
53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14<br />
X509v3 Authority Key Identifier: <br />
keyid:53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14<br />
<br />
X509v3 Basic Constraints: critical<br />
CA:TRUE<br />
Signature Algorithm: sha256WithRSAEncryption<br />
30:c2:f3:e0:96:51:7d:13:be:06:1d:40:06:70:b8:36:e9:46:<br />
81:64:0c:f0:e7:69:6f:31:2c:e1:86:df:f8:ad:b2:84:6e:90:<br />
4a:38:48:7d:ae:92:a5:71:40:c8:8e:0f:7e:67:e5:66:e7:70:<br />
4d:52:92:fa:a6:54:45:3b:a6:b9:b3:f4:35:ad:1c:6e:6e:15:<br />
06:81:ef:13:54:80:89:2e:7d:75:06:22:59:89:44:a9:ad:25:<br />
30:6c:02:e1:3b:2e:e2:bc:46:90:d1:a5:00:eb:87:57:60:a4:<br />
cf:e0:03:4a:b5:32:c4:dc:c7:e3:34:d4:c8:af:e3:ce:20:8c:<br />
c4:7f:f0:b8:72:d7:65:3b:38:be:2b:b1:d0:4e:9e:e2:52:32:<br />
41:fe:22:d2:7c:13:60:fe:4a:13:4b:c5:09:f0:00:89:32:22:<br />
47:4d:2c:a1:21:8e:b2:7d:0f:1a:10:f5:94:ee:fb:18:d3:15:<br />
f1:9e:70:89:73:c4:41:71:0e:92:22:9c:18:ef:0b:b1:7c:42:<br />
41:e7:9f:e7:82:d5:db:f3:60:d3:2f:2a:86:e4:0c:c0:4c:0c:<br />
17:12:ec:e4:37:96:dc:2d:01:00:22:ac:b5:33:6b:97:41:d7:<br />
37:e5:75:fa:c9:6b:00:2a:d8:87:0f:9e:f3:aa:c5:23:4e:60:<br />
02:a9:5b:eb<br />
</pre><br />
<br />
Видим, что сертификат подписан сам своим-же приватным ключом (Issuer: CN = MY CA, Subject: CN = MY CA)<br />
и выписан на 10 лет: начная с "Feb 4 14:30:01 2019 GMT" (для этого мы указывали -days 3650 в команде подписи)<br />
<br />
Таким образом цепочка доверия (проверки) выстраивается следующим образом:<br />
<br />
Сертификат устройства подписан сертификатом CA и может быть им проверен:<br />
<pre><br />
openssl verify -CAfile ca.crt device_AP6V5MDG.crt <br />
device_AP6V5MDG.crt: OK<br />
</pre><br />
<br />
Ну а сам сертификат подписан "собой":<br />
<pre><br />
openssl verify -CAfile ca.crt ca.crt<br />
ca.crt: OK<br />
</pre><br />
'''<br />
<br />
<br />
== Настройка nginx. ==<br />
<br />
Допустим в интернете есть сервер, который должен обрабатывать запросы только от устройств обладающих сертификатами,<br />
выписанными нашим CA.<br />
Для включения такой проверки в конфигурационном файле nginx необходимо в секции http или server прописать следующие строчки:<br />
<br />
<pre><br />
ssl_client_certificate ca.crt;<br />
ssl_verify_client on;<br />
</pre><br />
<br />
Теперь nginx будет требовать от клиента сертификат, который должен проходить проверку с помощью ca.crt, иначе сервер<br />
вернет клиенту ошибку 400:<br />
<br />
<pre><br />
curl https://example.com<br />
<html><br />
<head><title>400 No required SSL certificate was sent</title></head><br />
<body bgcolor="white"><br />
<center><h1>400 Bad Request</h1></center><br />
<center>No required SSL certificate was sent</center><br />
<hr><center>nginx/1.14.0 (Ubuntu)</center><br />
</body><br />
</html><br />
</pre><br />
<br />
Теперь сделаем так, чтобы HTTP запросы с контроллера WB проходили данную проверку.<br />
Для простоты будем использовать nginx и на клиентской стороне. Это даст возможность работать<br />
с защищенными серверами клиентам не умеющим делать SSL соединения.<br />
<br />
Для начала создадим на неиспользуемом локальном порту http сервер, который будет делать<br />
всю https "магию" за нас:<br />
<br />
<pre><br />
server {<br />
listen 8080;<br />
location / { <br />
proxy_pass https://example.com;<br />
proxy_ssl_name example.com;<br />
proxy_ssl_server_name on; <br />
proxy_ssl_certificate device_AP6V5MDG.crt;<br />
proxy_ssl_certificate_key engine:ateccx08:ATECCx08:00:04:C0:00;<br />
} <br />
}<br />
</pre><br />
<br />
Добавим пользователя www-data в группу i2c для доступа к криптоустройству:<br />
<pre><br />
usermod -G www-data<br />
</pre><br />
<br />
Выполним команду '''service nginx restart''' для обновления конфигурации.<br />
<br />
Теперь при обращении по http на локальный порт 8080 зашифрованные запросы с аутентификационной<br />
информацией будут отправлятся на сервер example.com.<br />
<br />
<pre><br />
curl localhost:8080/<br />
<html><br />
<body><br />
EXAMPLE.COM<br />
</body><br />
</html><br />
</pre><br />
<br />
== Настройка openvpn ==<br />
<br />
Для начала установим пакет:<br />
<br />
<pre><br />
apt install openvpn<br />
</pre><br />
<br />
Cоздадим файл req.cnf - он нам потребуется для создания сертификата сервера. <br />
<pre><br />
[ v3_req ]<br />
basicConstraints = CA:FALSE<br />
keyUsage = nonRepudiation, digitalSignature, keyEncipherment<br />
extendedKeyUsage = serverAuth, clientAuth<br />
</pre><br />
<br />
Серверу openvpn также требуется файл с параметрами DH, сделаем его.<br />
<pre><br />
openssl dhparam -out dh2048.pem 2048<br />
</pre><br />
<br />
Создание данного файла может потребовать несколько минут. <br />
<br />
Далее сделаем приватный ключ нашего сервера и запрос на сертификат. Предполагаем, для примера, что<br />
сервер имеет имя example.com:<br />
<br />
<pre> <br />
openssl genrsa -out example.key 2048<br />
<br />
openssl req -new -key example.key -subj "/CN=example.com" -out example.csr<br />
</pre><br />
<br />
Подписываем запрос в нашем центре сертификации:<br />
<br />
<pre><br />
openssl x509 -req -in example.csr -CA ca.crt -CAkey ca.key -out example.crt -days 365 -CAcreateserial -extfile req.cnf -extensions v3_req<br />
</pre><br />
<br />
Теперь приступим к настройке openvpn сервера на машине example.com.<br />
<br />
Копируем файлы '''ca.crt''', '''example.crt''', '''example.key''' и '''dh2048.pem''' и редактируем файл конфигурации openvpn сервера.<br />
По умолчанию конфигурационный файл лежит в файле /etc/openvpn/server.conf<br />
<br />
<pre><br />
port 1194<br />
proto tcp <br />
dev tun <br />
ca /etc/openvpn/server/ca.crt<br />
cert /etc/openvpn/server/example.crt<br />
key /etc/openvpn/server/example.key<br />
dh /etc/openvpn/server/dh2048.pem<br />
topology subnet<br />
server 10.8.0.0 255.255.255.0<br />
keepalive 10 60<br />
key-direction 0<br />
cipher AES-128-CBC<br />
auth SHA256<br />
comp-lzo<br />
user nobody<br />
group nogroup<br />
persist-key<br />
persist-tun<br />
status /var/run/openvpn/openvpn-status.log<br />
management 127.0.0.1 7500<br />
log-append /var/log/openvpn.log<br />
</pre><br />
<br />
Добавим пользователя openvpn в группу i2c для доступа к криптоустройству:<br />
<br />
<pre><br />
usermod -G www-data<br />
</pre><br />
<br />
после этого запускаем сервер командой <br />
service openvpn start.<br />
<br />
Далее на контроллере создаем файл конфигурации клиента:<br />
client.ovpn:<br />
-------------------------------------------------------------------------<br />
client<br />
dev tun<br />
proto tcp<br />
remote example.com 1194<br />
resolv-retry infinite<br />
nobind<br />
user openvpn<br />
'''group i2c'''<br />
persist-key<br />
persist-tun<br />
cipher AES-128-CBC<br />
auth SHA256<br />
key-direction 1<br />
keepalive 1 10<br />
remote-cert-tls server<br />
comp-lzo<br />
-------------------------------------------------------------------------<br />
<br />
Обратите внимание на строчку group i2c. Она необходима для работы с криптоустройством.<br />
<br />
После этого запускаем клиента:<br />
<br />
<pre><br />
openvpn --config example.ovpn --ca ca.crt --cert device_AP6V5MDG.crt --key engine:ateccx08:ATECCx08:00:04:C0:00<br />
</pre><br />
<br />
Если все хорошо, то в системе должен появиться интерфейс tun0 с адресом из подсети 10.8.0.0/24:<br />
<br />
<pre><br />
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500<br />
inet 10.8.0.2 netmask 255.255.255.0 destination 10.8.0.2<br />
inet6 fe80::53b0:83f3:b1f5:b817 prefixlen 64 scopeid 0x20<link><br />
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)<br />
RX packets 0 bytes 0 (0.0 B)<br />
RX errors 0 dropped 0 overruns 0 frame 0<br />
TX packets 6 bytes 288 (288.0 B)<br />
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0<br />
</pre><br />
<br />
Для проверки работоспособности запускаем ping:<br />
<br />
<pre><br />
ping 10.8.0.1<br />
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.<br />
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=2.23 ms<br />
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=2.83 ms<br />
</pre><br />
<br />
== Настройка mosquitto ==<br />
<br />
Генерируем приватный ключ и запрос на сртификат:<br />
<br />
<pre><br />
openssl genrsa -out example.key 2048<br />
openssl req -new -key example.key -subj "/CN=example.com" -out example.csr<br />
</pre><br />
<br />
Создаем сертификат сервера в CA.<br />
<pre><br />
openssl x509 -req -in example.csr -CA ca.crt -CAkey ca.key -out example.crt -days 365 -CAcreateserial -extfile req.cnf -extensions v3_req<br />
</pre><br />
<br />
Копируем файлы '''ca.crt''', '''mosquitto.crt''', '''mosquitto.key''' на сервер и редактируем файл конфигурации:<br />
<br />
/etc/mosquitto/conf.d/server.conf<br />
<br />
<pre><br />
cafile /etc/mosquitto/ssl/ca.crt<br />
certfile /etc/mosquitto/ssl/mosquitto.crt<br />
keyfile /etc/mosquitto/ssl/mosquitto.key<br />
require_certificate true<br />
use_identity_as_username true<br />
</pre><br />
<br />
Запускаем серис:<br />
<pre><br />
service mosquitto start<br />
</pre><br />
<br />
Также, если требуется, можно сделать чтобы локальный mosquitto сервер на контроллере<br />
форвардил некоторые топики на удаленный сервер. Для этого создаем файл бриджа: '''/etc/mosquitto/bridge.conf'''<br />
<br />
<pre><br />
connection main<br />
topic test/# out<br />
address example.com:1883<br />
<br />
bridge_cafile /etc/mosquitto/certs/ca.crt<br />
bridge_certfile /etc/mosquitto/certs/device_AP6V5MDG.crt<br />
bridge_keyfile engine:ateccx08:ATECCx08:00:04:C0:00<br />
</pre><br />
<br />
После перезапуска локального сервиса mosquitto топики /test/.. будут отправлятся на удаленный сервер example.com<br />
по защищенному ssl каналу.<br />
<br />
Примеры клиентских команд mosquitto.<br />
Отправка сообщения "message" в топик "test" на сервере example.com <br />
<br />
<pre><br />
mosquitto_pub -h example.com --cert device_AP6V5MDG.crt --key 'engine:ateccx08:ATECCx08:00:04:C0:00' --cafile ca.crt -t "test" -m "message" <br />
</pre><br />
<br />
Получение сообщений из топика "test" на сервере example.com<br />
<br />
<pre><br />
mosquitto_sub -h example.com --cert device_AP6V5MDG.crt --key 'engine:ateccx08:ATECCx08:00:04:C0:00' -t "test" --cafile ca.crt<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17012CryptodevATECCx08 Auth2019-02-05T15:36:16Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: '''nginx''', '''openssl''', '''mosquitto'''.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее командой:<br />
<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre><br />
<br />
Теперь приступим к созданию сертификатов.<br />
Для начала создадим свой центр сертификации (Certification Authority, '''CA'''):<br />
<br />
Для этого сгенерируем ключевую пару:<br />
<pre>openssl genrsa -out ca.key 2048</pre><br />
<br />
И сертификат нашего '''CA''':<br />
<br />
<pre>openssl req -x509 -new -days 3650 -key ca.key -out ca.crt -subj "/CN=MY CA"</pre><br />
<br />
'''CA''' является основой безопасности в данной схеме, поэтому эти операции выполняем на машине доступ к которой<br />
есть только у владельца '''CA'''.<br />
<br />
Далее на конроллере WB создаем запрос на сертификат устройства:<br />
<br />
<pre>openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device_AP6V5MDG.csr</pre><br />
<br />
В этой команде мы указываем, что запрос подписывается приватным ключом, находящимся в криптоустройстве ateccx08 ключом<br />
с идентификатором '''ATECCx08:00:04:C0:00''' и публичным именем wirenboard-AP6V5MDG. Запрос помещаем в файл device_AP6V5MDG.csr.<br />
<br />
Имя можно выбрать любое уникальное, удобно для этой цели спользовать идентификатор устройства, который по умолчанию прописывается<br />
в файле /etc/hostname:<br />
<br />
<pre><br />
cat /etc/hostname<br />
wirenboard-AP6V5MDG<br />
</pre><br />
<br />
Далее этот запрос подписываем в нашем центре сертификации:<br />
openssl x509 -req -in device_AP6V5MDG.csr -CA ca.crt -CAkey ca.key -out device_AP6V5MDG.crt -days 365 -CAcreateserial<br />
<br />
В этой команде мы уазываем файл запроса, и файлы CA необходимые для подписи. В итоге получаем сертификат устройства device_AP6V5MDG.crt.<br />
Файл '''device_AP6V5MDG.crt''' копируем на контроллер WB, он будет необходим для авторизацци.<br />
<br />
Давайте посмотрим, что содержится в файлах сертификатов CA и устройства:<br />
<br />
<pre><br />
openssl x509 -text -noout -in device_AP6V5MDG.crt<br />
<br />
Certificate:<br />
Data:<br />
Version: 1 (0x0)<br />
Serial Number:<br />
bf:85:29:be:19:67:f5:3e<br />
Signature Algorithm: sha256WithRSAEncryption<br />
Issuer: CN = MY CA<br />
Validity<br />
Not Before: Feb 4 14:50:14 2019 GMT<br />
Not After : Feb 4 14:50:14 2020 GMT<br />
Subject: CN = wirenboard-AP6V5MDG<br />
Subject Public Key Info:<br />
Public Key Algorithm: id-ecPublicKey<br />
Public-Key: (256 bit)<br />
pub:<br />
04:66:80:f6:83:ea:4f:88:a5:05:df:8f:2c:62:f3:<br />
ad:71:55:87:7f:ae:12:ae:b1:74:4b:68:68:fd:f7:<br />
e0:8a:f4:44:87:45:ab:c1:07:3f:54:2a:a9:ea:c6:<br />
71:1d:41:63:67:1b:75:f4:00:42:8d:fd:f6:d5:b6:<br />
52:38:e8:5a:a9<br />
ASN1 OID: prime256v1<br />
NIST CURVE: P-256<br />
Signature Algorithm: sha256WithRSAEncryption<br />
be:d1:f8:04:fb:34:a9:84:ff:25:b6:04:04:c0:f1:1d:4a:a4:<br />
04:b8:54:6c:a8:46:61:5f:6c:e7:ab:16:8f:ae:45:46:02:99:<br />
c6:d3:90:42:91:20:c7:89:d5:cf:4e:23:3a:33:64:ab:1b:c9:<br />
78:18:82:f4:39:8b:97:ae:6c:ee:a4:13:0c:5a:54:6b:69:c8:<br />
1e:fa:24:3d:48:2c:ea:0e:5c:0d:c3:43:c2:49:ea:b2:f8:5e:<br />
d7:0b:b5:4e:67:87:53:84:76:23:aa:10:77:5d:f1:21:9e:b0:<br />
4b:16:99:7c:d4:d3:d6:e7:00:9c:bf:53:a1:4b:f4:2c:fc:0b:<br />
64:10:fb:77:fc:3d:b2:71:cf:be:0b:b1:a2:62:ed:8c:92:e4:<br />
78:73:dc:69:c4:61:10:22:66:11:11:8b:d4:3c:b6:4f:7f:2c:<br />
24:07:61:47:15:2a:56:7e:71:69:59:15:8b:53:c8:e2:b5:ed:<br />
34:a0:78:70:d4:f6:cf:0f:6d:df:45:00:3b:0a:39:a2:fb:e7:<br />
89:f3:d9:88:7f:6b:bd:fa:ca:5e:44:94:74:70:5e:86:0b:93:<br />
ca:16:71:42:67:eb:77:bd:15:e3:90:2f:68:fd:bc:61:25:a3:<br />
a6:e7:8b:b1:42:bc:c2:36:d4:17:67:b3:77:fb:bd:06:e9:35:<br />
3b:8e:08:48<br />
</pre><br />
<br />
Видим, что сертификат выписан Центром сертификации с именем "MY CA" на 1 год, начная с "Feb 4 14:50:14 2019 GMT" (для этого мы указывали -days 365 в команде подписи),<br />
устройству с именем '''wirenboard-AP6V5MDG''', имеющим приватный ключ соответствующий публичному Subject Public Key Info.<br />
Сертификат подписан цифровой подписью. <br />
<br />
Цифровая подпись гарантирует, что никакая часть сертификата не может быть незаметно изменена. В случае изменения проверка публичным<br />
ключом '''CA''' даст ошибку.<br />
<br />
<pre><br />
openssl x509 -text -noout -in ca.crt<br />
<br />
Certificate:<br />
Data:<br />
Version: 3 (0x2)<br />
Serial Number:<br />
d9:e0:91:e7:d0:27:02:db<br />
Signature Algorithm: sha256WithRSAEncryption<br />
Issuer: CN = MY CA<br />
Validity<br />
Not Before: Feb 4 14:30:01 2019 GMT<br />
Not After : Feb 1 14:30:01 2029 GMT<br />
Subject: CN = MY CA<br />
Subject Public Key Info:<br />
Public Key Algorithm: rsaEncryption<br />
Public-Key: (2048 bit)<br />
Modulus:<br />
00:c8:5e:02:b8:55:e5:42:97:f7:c6:53:61:d3:df:<br />
66:bf:05:dd:7a:0c:61:a4:68:36:23:3f:3b:c7:83:<br />
ec:47:9b:5a:ed:78:8a:5b:f1:5f:88:3d:36:f2:3e:<br />
7b:84:9e:1b:e5:87:bf:3b:00:33:36:1c:0b:3a:16:<br />
2f:8d:be:0e:a4:9e:25:73:4d:93:8a:47:74:29:65:<br />
0e:4e:ea:44:fd:c4:c0:bf:fa:bc:11:d5:93:43:e2:<br />
65:18:bb:f7:e5:fc:16:8c:f9:11:97:76:2c:bb:cb:<br />
c0:94:7e:78:12:20:c9:8a:68:29:c1:e8:af:7e:d7:<br />
63:6e:a3:57:79:c9:b3:a8:8c:a3:2d:3e:15:1a:25:<br />
ea:f1:50:fc:ea:93:8f:14:5f:34:61:07:a9:dc:24:<br />
b8:11:de:9c:17:13:03:19:0d:0c:a3:e8:10:31:50:<br />
82:5b:cb:0e:26:d5:b1:fe:df:c3:f6:f9:e4:0f:b1:<br />
24:40:f2:8d:95:d5:ea:34:b3:27:a1:87:76:9d:f2:<br />
65:74:d5:40:47:dd:a1:32:46:c3:37:ec:a5:b3:09:<br />
30:73:99:d1:9c:bb:a8:05:61:2a:56:89:32:5e:c0:<br />
5d:1d:b6:a6:b6:74:17:be:74:69:9c:b0:e3:bc:b4:<br />
f9:96:6d:aa:60:ae:70:d1:ee:07:e5:2c:5d:0a:af:<br />
ce:b3<br />
Exponent: 65537 (0x10001)<br />
X509v3 extensions:<br />
X509v3 Subject Key Identifier: <br />
53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14<br />
X509v3 Authority Key Identifier: <br />
keyid:53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14<br />
<br />
X509v3 Basic Constraints: critical<br />
CA:TRUE<br />
Signature Algorithm: sha256WithRSAEncryption<br />
30:c2:f3:e0:96:51:7d:13:be:06:1d:40:06:70:b8:36:e9:46:<br />
81:64:0c:f0:e7:69:6f:31:2c:e1:86:df:f8:ad:b2:84:6e:90:<br />
4a:38:48:7d:ae:92:a5:71:40:c8:8e:0f:7e:67:e5:66:e7:70:<br />
4d:52:92:fa:a6:54:45:3b:a6:b9:b3:f4:35:ad:1c:6e:6e:15:<br />
06:81:ef:13:54:80:89:2e:7d:75:06:22:59:89:44:a9:ad:25:<br />
30:6c:02:e1:3b:2e:e2:bc:46:90:d1:a5:00:eb:87:57:60:a4:<br />
cf:e0:03:4a:b5:32:c4:dc:c7:e3:34:d4:c8:af:e3:ce:20:8c:<br />
c4:7f:f0:b8:72:d7:65:3b:38:be:2b:b1:d0:4e:9e:e2:52:32:<br />
41:fe:22:d2:7c:13:60:fe:4a:13:4b:c5:09:f0:00:89:32:22:<br />
47:4d:2c:a1:21:8e:b2:7d:0f:1a:10:f5:94:ee:fb:18:d3:15:<br />
f1:9e:70:89:73:c4:41:71:0e:92:22:9c:18:ef:0b:b1:7c:42:<br />
41:e7:9f:e7:82:d5:db:f3:60:d3:2f:2a:86:e4:0c:c0:4c:0c:<br />
17:12:ec:e4:37:96:dc:2d:01:00:22:ac:b5:33:6b:97:41:d7:<br />
37:e5:75:fa:c9:6b:00:2a:d8:87:0f:9e:f3:aa:c5:23:4e:60:<br />
02:a9:5b:eb<br />
</pre><br />
<br />
Видим, что сертификат подписан сам своим-же приватным ключом (Issuer: CN = MY CA, Subject: CN = MY CA)<br />
и выписан на 10 лет: начная с "Feb 4 14:30:01 2019 GMT" (для этого мы указывали -days 3650 в команде подписи)<br />
<br />
Таким образом цепочка доверия (проверки) выстраивается следующим образом:<br />
<br />
Сертификат устройства подписан сертификатом CA и может быть им проверен:<br />
<pre><br />
openssl verify -CAfile ca.crt device_AP6V5MDG.crt <br />
device_AP6V5MDG.crt: OK<br />
</pre><br />
<br />
Ну а сам сертификат подписан "собой":<br />
<pre><br />
openssl verify -CAfile ca.crt ca.crt<br />
ca.crt: OK<br />
</pre><br />
'''<br />
<br />
<br />
Настройка nginx.<br />
<br />
Допустим в интернете есть сервер, который должен обрабатывать запросы только от устройств обладающих сертификатами,<br />
выписанными нашим CA.<br />
Для включения такой проверки в конфигурационном файле nginx необходимо в секции http или server прописать следующие строчки:<br />
<br />
<pre><br />
ssl_client_certificate ca.crt;<br />
ssl_verify_client on;<br />
</pre><br />
<br />
Теперь nginx будет требовать от клиента сертификат, который должен проходить проверку с помощью ca.crt, иначе сервер<br />
вернет клиенту ошибку 400:<br />
<br />
<pre><br />
curl https://example.com<br />
<html><br />
<head><title>400 No required SSL certificate was sent</title></head><br />
<body bgcolor="white"><br />
<center><h1>400 Bad Request</h1></center><br />
<center>No required SSL certificate was sent</center><br />
<hr><center>nginx/1.14.0 (Ubuntu)</center><br />
</body><br />
</html><br />
</pre><br />
<br />
Теперь сделаем так, чтобы HTTP запросы с контроллера WB проходили данную проверку.<br />
Для простоты будем использовать nginx и на клиентской стороне. Это даст возможность работать<br />
с защищенными серверами клиентам не умеющим делать SSL соединения.<br />
<br />
Для начала создадим на неиспользуемом локальном порту http сервер, который будет делать<br />
всю https "магию" за нас:<br />
<br />
<pre><br />
server {<br />
listen 8080;<br />
location / { <br />
proxy_pass https://example.com;<br />
proxy_ssl_name example.com;<br />
proxy_ssl_server_name on; <br />
proxy_ssl_certificate device_AP6V5MDG.crt;<br />
proxy_ssl_certificate_key engine:ateccx08:ATECCx08:00:04:C0:00;<br />
} <br />
}<br />
</pre><br />
<br />
Добавим пользователя www-data в группу i2c для доступа к криптоустройству:<br />
<pre><br />
usermod -G www-data<br />
</pre><br />
<br />
Выполним команду '''service nginx restart''' для обновления конфигурации.<br />
<br />
Теперь при обращении по http на локальный порт 8080 зашифрованные запросы с аутентификационной<br />
информацией будут отправлятся на сервер example.com.<br />
<br />
<pre><br />
curl localhost:8080/<br />
<html><br />
<body><br />
EXAMPLE.COM<br />
</body><br />
</html><br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17011CryptodevATECCx08 Auth2019-02-05T14:58:01Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: '''nginx''', '''openssl''', '''mosquitto'''.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее командой:<br />
<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre><br />
<br />
Теперь приступим к созданию сертификатов.<br />
Для начала создадим свой центр сертификации (Certification Authority, '''CA'''):<br />
<br />
Для этого сгенерируем ключевую пару:<br />
<pre>openssl genrsa -out ca.key 2048<pre><br />
<br />
И сертификат нашего '''CA''':<br />
<br />
<pre>openssl req -x509 -new -days 3650 -key ca.key -out ca.crt -subj "/CN=MY CA"</pre><br />
<br />
'''CA''' является основой безопасности в данной схеме, поэтому эти операции выполняем на машине доступ к которой<br />
есть только у владельца '''CA'''.<br />
<br />
Далее на конроллере WB создаем запрос на сертификат устройства:<br />
<br />
<pre>openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device_AP6V5MDG.csr</pre><br />
<br />
В этой команде мы указываем, что запрос подписывается приватным ключом, находящимся в криптоустройстве ateccx08 ключом<br />
с идентификатором '''ATECCx08:00:04:C0:00''' и публичным именем wirenboard-AP6V5MDG. Запрос помещаем в файл device_AP6V5MDG.csr.<br />
<br />
Имя можно выбрать любое уникальное, удобно для этой цели спользовать идентификатор устройства, который по умолчанию прописывается<br />
в файле /etc/hostname:<br />
<br />
<pre><br />
cat /etc/hostname<br />
wirenboard-AP6V5MDG<br />
</pre><br />
<br />
Далее этот запрос подписываем в нашем центре сертификации:<br />
openssl x509 -req -in device_AP6V5MDG.csr -CA ca.crt -CAkey ca.key -out device_AP6V5MDG.crt -days 365 -CAcreateserial<br />
<br />
В этой команде мы уазываем файл запроса, и файлы CA необходимые для подписи. В итоге получаем сертификат устройства device_AP6V5MDG.crt.<br />
Файл '''device_AP6V5MDG.crt''' копируем на контроллер WB, он будет необходим для авторизацци.<br />
<br />
Давайте посмотрим, что содержится в файлах сертификатов CA и устройства:<br />
<br />
<pre><br />
openssl x509 -text -noout -in device_AP6V5MDG.crt<br />
<br />
Certificate:<br />
Data:<br />
Version: 1 (0x0)<br />
Serial Number:<br />
bf:85:29:be:19:67:f5:3e<br />
Signature Algorithm: sha256WithRSAEncryption<br />
Issuer: CN = MY CA<br />
Validity<br />
Not Before: Feb 4 14:50:14 2019 GMT<br />
Not After : Feb 4 14:50:14 2020 GMT<br />
Subject: CN = wirenboard-AP6V5MDG<br />
Subject Public Key Info:<br />
Public Key Algorithm: id-ecPublicKey<br />
Public-Key: (256 bit)<br />
pub:<br />
04:66:80:f6:83:ea:4f:88:a5:05:df:8f:2c:62:f3:<br />
ad:71:55:87:7f:ae:12:ae:b1:74:4b:68:68:fd:f7:<br />
e0:8a:f4:44:87:45:ab:c1:07:3f:54:2a:a9:ea:c6:<br />
71:1d:41:63:67:1b:75:f4:00:42:8d:fd:f6:d5:b6:<br />
52:38:e8:5a:a9<br />
ASN1 OID: prime256v1<br />
NIST CURVE: P-256<br />
Signature Algorithm: sha256WithRSAEncryption<br />
be:d1:f8:04:fb:34:a9:84:ff:25:b6:04:04:c0:f1:1d:4a:a4:<br />
04:b8:54:6c:a8:46:61:5f:6c:e7:ab:16:8f:ae:45:46:02:99:<br />
c6:d3:90:42:91:20:c7:89:d5:cf:4e:23:3a:33:64:ab:1b:c9:<br />
78:18:82:f4:39:8b:97:ae:6c:ee:a4:13:0c:5a:54:6b:69:c8:<br />
1e:fa:24:3d:48:2c:ea:0e:5c:0d:c3:43:c2:49:ea:b2:f8:5e:<br />
d7:0b:b5:4e:67:87:53:84:76:23:aa:10:77:5d:f1:21:9e:b0:<br />
4b:16:99:7c:d4:d3:d6:e7:00:9c:bf:53:a1:4b:f4:2c:fc:0b:<br />
64:10:fb:77:fc:3d:b2:71:cf:be:0b:b1:a2:62:ed:8c:92:e4:<br />
78:73:dc:69:c4:61:10:22:66:11:11:8b:d4:3c:b6:4f:7f:2c:<br />
24:07:61:47:15:2a:56:7e:71:69:59:15:8b:53:c8:e2:b5:ed:<br />
34:a0:78:70:d4:f6:cf:0f:6d:df:45:00:3b:0a:39:a2:fb:e7:<br />
89:f3:d9:88:7f:6b:bd:fa:ca:5e:44:94:74:70:5e:86:0b:93:<br />
ca:16:71:42:67:eb:77:bd:15:e3:90:2f:68:fd:bc:61:25:a3:<br />
a6:e7:8b:b1:42:bc:c2:36:d4:17:67:b3:77:fb:bd:06:e9:35:<br />
3b:8e:08:48<br />
</pre><br />
<br />
Видим, что сертификат выписан Центром сертификации с именем "MY CA" на 1 год, начная с "Feb 4 14:50:14 2019 GMT" (для этого мы указывали -days 365 в команде подписи),<br />
устройству с именем '''wirenboard-AP6V5MDG''', имеющим приватный ключ соответствующий публичному Subject Public Key Info.<br />
Сертификат подписан цифровой подписью. <br />
<br />
Цифровая подпись гарантирует, что никакая часть сертификата не может быть незаметно изменена. В случае изменения проверка публичным<br />
ключом '''CA''' даст ошибку.</div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17010CryptodevATECCx08 Auth2019-02-05T14:50:25Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: '''nginx''', '''openssl''', '''mosquitto'''.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее командой:<br />
<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre><br />
<br />
Теперь приступим к созданию сертификатов.<br />
Для начала создадим свой центр сертификации (Certification Authority, '''CA'''):<br />
<br />
Для этого сгенерируем ключевую пару:<br />
<br />
'''openssl genrsa -out ca.key 2048'''<br />
<br />
И сертификат нашего '''CA''':<br />
<br />
<pre>openssl req -x509 -new -days 3650 -key ca.key -out ca.crt -subj "/CN=MY CA"</pre><br />
<br />
'''CA''' является основой безопасности в данной схеме, поэтому эти операции выполняем на машине доступ к которой<br />
есть только у владельца '''CA'''.<br />
<br />
Далее на конроллере WB создаем запрос на сертификат устройства:<br />
<br />
<pre>openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device_AP6V5MDG.csr</pre><br />
<br />
В этой команде мы указываем, что запрос подписывается приватным ключом, находящимся в криптоустройстве ateccx08 ключом<br />
с идентификатором '''ATECCx08:00:04:C0:00''' и публичным именем wirenboard-AP6V5MDG. Запрос помещаем в файл device_AP6V5MDG.csr.<br />
<br />
Имя можно выбрать любое уникальное, удобно для этой цели спользовать идентификатор устройства, который по умолчанию прописывается<br />
в файле /etc/hostname:<br />
<br />
cat /etc/hostname<br />
wirenboard-AP6V5MDG<br />
<br />
Далее этот запрос подписываем в нашем центре сертификации:<br />
openssl x509 -req -in device_AP6V5MDG.csr -CA ca.crt -CAkey ca.key -out device_AP6V5MDG.crt -days 365 -CAcreateserial<br />
<br />
В этой команде мы уазываем файл запроса, и файлы CA необходимые для подписи. В итоге получаем сертификат устройства device_AP6V5MDG.crt.<br />
Файл device_AP6V5MDG.crt копируем на контроллер WB, он будет необходим для авторизацци.<br />
<br />
Давайте посмотрим, что содержится в файлах сертификатов CA и устройства:</div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17009CryptodevATECCx08 Auth2019-02-05T14:48:16Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: '''nginx''', '''openssl''', '''mosquitto'''.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее командой:<br />
<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre><br />
<br />
Теперь приступим к созданию сертификатов.<br />
Для начала создадим свой центр сертификации (Certification Authority, '''CA'''):<br />
<br />
Для этого сгенерируем ключевую пару:<br />
<br />
'''openssl genrsa -out ca.key 2048'''<br />
<br />
И сертификат нашего '''CA''':<br />
<br />
'''openssl req -x509 -new -days 3650 -key ca.key -out ca.crt -subj "/CN=MY CA"'''<br />
<br />
'''CA''' является основой безопасности в данной схеме, поэтому эти операции выполняем на машине доступ к которой<br />
есть только у владельца '''CA'''.<br />
<br />
Далее на конроллере WB создаем запрос на сертификат устройства:<br />
<br />
openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device_AP6V5MDG.csr<br />
<br />
В этой команде мы указываем, что запрос подписывается приватным ключом, находящимся в криптоустройстве ateccx08 ключом<br />
с идентификатором ATECCx08:00:04:C0:00 и публичным именем wirenboard-AP6V5MDG. Запрос помещаем в файл device_AP6V5MDG.csr.<br />
<br />
Имя можно выбрать любое уникальное, удобно для этой цели спользовать идентификатор устройства, который по умолчанию прописывается<br />
в файле /etc/hostname:<br />
<br />
cat /etc/hostname<br />
wirenboard-AP6V5MDG<br />
<br />
Далее этот запрос подписываем в нашем центре сертификации:<br />
openssl x509 -req -in device_AP6V5MDG.csr -CA ca.crt -CAkey ca.key -out device_AP6V5MDG.crt -days 365 -CAcreateserial<br />
<br />
В этой команде мы уазываем файл запроса, и файлы CA необходимые для подписи. В итоге получаем сертификат устройства device_AP6V5MDG.crt.<br />
Файл device_AP6V5MDG.crt копируем на контроллер WB, он будет необходим для авторизацци.<br />
<br />
Давайте посмотрим, что содержится в файлах сертификатов CA и устройства:</div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17008CryptodevATECCx08 Auth2019-02-05T14:47:19Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: nginx, openssl, mosquitto.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее командой:<br />
<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre><br />
<br />
Теперь приступим к созданию сертификатов.<br />
Для начала создадим свой центр сертификации (Certification Authority, CA):<br />
<br />
Для этого сгенерируем ключевую пару:<br />
<br />
'''openssl genrsa -out ca.key 2048'''<br />
<br />
И сертификат нашего CA:<br />
<br />
'''openssl req -x509 -new -days 3650 -key ca.key -out ca.crt -subj "/CN=MY CA"'''<br />
<br />
'''CA''' является основой безопасности в данной схеме, поэтому эти операции выполняем на машине доступ к которой<br />
есть только у владельца '''CA'''.<br />
<br />
Далее на конроллере WB создаем запрос на сертификат устройства:<br />
<br />
openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device_AP6V5MDG.csr<br />
<br />
В этой команде мы указываем, что запрос подписывается приватным ключом, находящимся в криптоустройстве ateccx08 ключом<br />
с идентификатором ATECCx08:00:04:C0:00 и публичным именем wirenboard-AP6V5MDG. Запрос помещаем в файл device_AP6V5MDG.csr.<br />
<br />
Имя можно выбрать любое уникальное, удобно для этой цели спользовать идентификатор устройства, который по умолчанию прописывается<br />
в файле /etc/hostname:<br />
<br />
cat /etc/hostname<br />
wirenboard-AP6V5MDG<br />
<br />
Далее этот запрос подписываем в нашем центре сертификации:<br />
openssl x509 -req -in device_AP6V5MDG.csr -CA ca.crt -CAkey ca.key -out device_AP6V5MDG.crt -days 365 -CAcreateserial<br />
<br />
В этой команде мы уазываем файл запроса, и файлы CA необходимые для подписи. В итоге получаем сертификат устройства device_AP6V5MDG.crt.<br />
Файл device_AP6V5MDG.crt копируем на контроллер WB, он будет необходим для авторизацци.<br />
<br />
Давайте посмотрим, что содержится в файлах сертификатов CA и устройства:</div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17007CryptodevATECCx08 Auth2019-02-05T14:43:57Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
В данной статье пойдет речь о трех вариантах применения: nginx, openssl, mosquitto.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17006CryptodevATECCx08 Auth2019-02-05T14:42:47Z<p>Xenols: /* Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. */</p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br><br />
<br><br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: nginx, openssl, mosquitto.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее<br />
<br />
'''apt install libateccssl1.1'''<br />
<br />
Далее нужно отредактировать файл '''/etc/ssl/openssl.cnf''', добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17005CryptodevATECCx08 Auth2019-02-05T14:42:08Z<p>Xenols: /* Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. */</p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br><br />
<br><br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: nginx, openssl, mosquitto.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее<br />
<br />
# apt install libateccssl1.1<br />
<br />
Далее нужно отредактировать файл /etc/ssl/openssl.cnf, добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17004CryptodevATECCx08 Auth2019-02-05T14:41:50Z<p>Xenols: /* Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. */</p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: nginx, openssl, mosquitto.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее<br />
<br />
# apt install libateccssl1.1<br />
<br />
Далее нужно отредактировать файл /etc/ssl/openssl.cnf, добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17003CryptodevATECCx08 Auth2019-02-05T14:41:20Z<p>Xenols: /* Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. */</p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар, хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: nginx, openssl, mosquitto.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее<br />
<br />
# apt install libateccssl1.1<br />
<br />
Далее нужно отредактировать файл /etc/ssl/openssl.cnf, добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17002CryptodevATECCx08 Auth2019-02-05T14:40:21Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар,<br />
хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается<br />
его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних <br />
сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: nginx, openssl, mosquitto.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее<br />
<br />
# apt install libateccssl1.1<br />
<br />
Далее нужно отредактировать файл /etc/ssl/openssl.cnf, добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17001CryptodevATECCx08 Auth2019-02-05T14:39:44Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар,<br />
хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается<br />
его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних <br />
сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: nginx, openssl, mosquitto.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее<br />
<br />
# apt install libateccssl1.1<br />
<br />
Далее нужно отредактировать файл /etc/ssl/openssl.cnf, добавив в нем следующие строчки:<br />
<br />
<pre><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</pre></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=17000CryptodevATECCx08 Auth2019-02-05T14:38:30Z<p>Xenols: </p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры '''WirenBoard''' встроен чип '''ATECCx08''', назначением которого является генерация ключевых пар,<br />
хранение приватных ключей а также операции асимметричного шифрования с использованием эллиптических кривых.<br />
<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается<br />
его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних <br />
сервисах и быть уверенным, что запрос выполнен с использованием именно этого экземпляра микросхемы.<br />
<br />
В данной статье пойдет речь о трех вариантах применения: nginx, openssl, mosquitto.<br />
<br />
Для доступа к криптоустройству нужна библиотека libateccssl1.1, установим ее<br />
<br />
# apt install libateccssl1.1<br />
<br />
Далее нужно отредактировать файл /etc/ssl/openssl.cnf, добавив в нем следующие строчки:<br />
<code><br />
openssl_conf = openssl_init<br />
<br />
[openssl_init]<br />
engines = engine_section<br />
<br />
[engine_section]<br />
ateccx08 = ateccx08_section<br />
<br />
[ateccx08_section]<br />
init = 1<br />
</code></div>Xenolshttps://wirenboard.com/wiki/index.php?title=CryptodevATECCx08_Auth&diff=16993CryptodevATECCx08 Auth2019-02-01T16:18:53Z<p>Xenols: Новая страница: « == Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. == В контрол…»</p>
<hr />
<div><br />
== Использование встроенного чипа ATECCx08 для авторизации на внешних сервисах. ==<br />
<br />
В контроллеры WirenBoard встроен чип ATECCx08. Назначением этой микросхемы является генерация ключевых пар,<br />
хранение приватных ключей а также операции ассиметричного шифрования с использованием эллипических кривых.<br />
<br />
Приватный ключ после начальной инициализации хранится в микросхеме и не покидает ее, тем самым исключается<br />
его компрометация.<br />
<br />
Используя данную микросхему можно организовать авторизацию контроллера и защиту соединения по SSL на внешних сервисах.</div>Xenolshttps://wirenboard.com/wiki/index.php?title=WB-MAP6S_Modbus_Power_Meter&diff=16972WB-MAP6S Modbus Power Meter2019-02-01T12:07:37Z<p>Xenols: /* Характеристики */</p>
<hr />
<div>[[File:MAP6S.JPG|300px|thumb|right|Многоканальный счётчик электроэнергии WB-MAP6S]]<br />
'''[https://contactless.ru/store/%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9-%D0%B8%D0%B7%D0%BC%D0%B5%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C-WB-MAP6S-p100428579 Купить в интернет-магазине]'''<br />
{{DISPLAYTITLE:Многоканальный счётчик электроэнергии WB-MAP6S}} {{#vardefine:ProductName1|WB-MAP6S}} {{#vardefine:ProductFullName1|Многоканальный счётчик электроэнергии WB-MAP6S}} {{#vardefine:FileName1|WB-MAP6S}}<br />
== Назначение==<br />
Многоканальный счётчик электроэнергии (измеритель параметров электрической сети) WB-MAP6S предназначен для энергоменеджмента и мониторинга качества электропитания. <br />
<br />
Счётчик WB-MAP6S предназначен для работы в однофазных сетях переменного тока.<br />
<br />
Использование внешних разъёмных трансформаторов тока позволяет производить монтаж системы без отключения потребителей.<br />
<br />
<br />
Для активной энергии измеритель обеспечивает класс точности 0,5S. Для реактивной энергии - класс точности 1.<br />
<br />
== Модификации ==<br />
{| class="wikitable"<br />
! Модель<br />
! Тип<br />
|-<br />
| WB-MAP6SH<br />
| Модель с измерением коэффициентов гармоник тока и напряжения<br />
|-<br />
| WB-MAP6S<br />
| Модель без измерения коэффициентов гармоник тока и напряжения<br />
|}<br />
<br />
== Технические характеристики==<br />
=== Измеряемые параметры ===<br />
Полный список измеряемых параметров приводится на странице [[Power Meter WB-MAP12H Measuring Parameters|Счетчик WB-MAP12H: измеряемые параметры и погрешности, их названия в веб-инетрфейсе Wiren Board]]<br />
<br />
Амплитуды гармоник и коэффициент нелинейных искажений ('''THD''') по току и напряжению измеряются только в моделях с индексом с индексом "H".<br />
<br />
=== Характеристики ===<br />
<br />
{| class="wikitable"<br />
! style="text-align: center;" | Параметр<br />
! style="text-align: center;" | Значение<br />
|-<br />
! colspan="2" |Питание<br />
|-<br />
|Напряжение питания<br />
| 9 В—28 В постоянного тока<br />
|-<br />
|Потребляемая мощность максимальная<br />
|1 Вт ??<br />
|-<br />
|Потребляемая мощность средняя<br />
|0.9 Вт ??<br />
|-<br />
! colspan="2" |Каналы измерения<br />
|-<br />
|Число каналов<br />
| 6 однофазных<br />
|-<br />
|Анализируемые гармоники частоты напряжения и тока <br />
| 1 — 42 (только в модификации WB-MAP6S'''H''')<br />
|-<br />
! colspan="2" |Управление<br />
|-<br />
|Интерфейс управления<br />
|RS-485<br />
|-<br />
|Изоляция интерфейса<br />
|Гальванически развязанный от измерительных цепей<br />
|-<br />
|Протокол обмена данными<br />
|Modbus RTU, адрес задается программно, заводские настройки указаны на наклейке<br />
|-<br />
|Параметры интерфейса RS-485<br />
| <br />
По умолчанию: скорость 9600 бит/с; данные — 8 бит; четность N; стоп-биты 2; <br />
Параметры интерфейса могут быть настроены программно:<br />
*Скорость: 1200, 2400, 4800, 9600 (по умолчанию), 19200, 38400, 57600, 115200 бит/с <br>([[UART_Communication_Settings|Настройка параметров обмена данными по RS-485 для modbus-устройств Wiren Board]])<br />
*Данные: 8 бит <br />
*Проверка чётности: нет (по умолчанию), 1 - нечётный (odd), 2 - чётный (even) <br />
*Стоповых бит: 1, 2 (по умолчанию)<br />
<br />
|-<br />
|Готовность к работе после подачи питания<br />
| 1 c <br />
|-<br />
! colspan="2" |Габариты<br />
|-<br />
| Габариты<br />
| 53,3 x 90,2 x 57,5 мм <br />
|-<br />
! colspan="2" |Условия эксплуатации<br />
|-<br />
| Температура воздуха<br />
| от -40°С до +80°С<br />
|-<br />
| Относительная влажность воздуха<br />
| до 98%, без конденсации влаги<br />
|}<br />
<br />
=== Габаритные размеры счетчика ===<br />
<br />
[[File:DIN 3U.png |300px|thumb|right| Габаритные размеры модулей в корпусе 3 DIN]]<br />
Габаритные размеры модуля составляют 53,3 x 90,2 x 57,5 мм (Д x Ш х В), см. черт.<br />
<br />
== Питание счетчика ==<br />
Счетчик WB-MAP6S(H) '''получает питание только от интерфейсной части.''' При отсутствии питания на интерфейсной части измерения '''не''' производятся.<br />
<br />
Для непрерывного измерения потребления электроэнергии необходимо обеспечить надежное питание, например от отдельного блока питания.<br />
<br />
==Работа при провалах и прерываниях напряжения==<br />
Замер энергии прекращается при напряжении меньше 180 вольт (провал или прерывание напряжения), порог задается в одном из Modbus-регистров счетчика.<br />
<br />
== Обмен данными ==<br />
На физическом уровне модуль подключается через интерфейс RS-485. Для управления счетчиком используется протокол Modbus RTU. В устройствах Wirenboard данные Modbus передаются по линиям связи RS-485. Подробнее смотрите страницу [[Протокол Modbus]]. Modbus-адрес счетчика задается на заводе и нанесен на наклейке. Адрес может быть изменен программно. Подробности смотрите в разделе [[#Управление по Modbus|Управление по Modbus]].<br />
<br />
== Монтаж ==<br />
[[File:MAP6S-CONNECT.png |350px|thumb|right|Пример схемы подключения счетчика WB-MAP6S]]<br />
<br />
'''Важно! При монтаже счетчика клемма PE обязательно должна быть соединена с защитным заземлением, а на клемму N подключена нейтраль. Если защитное заземление (PE) не подключено, то при случайном появлении фазового напряжения на клемме одного из токовых трансформаторов, то опасное для жизни фазовое напряжение появляется и на остальных клеммах. Если защитное заземление подключено - то опасного напряжения на клеммах остальных трансформаторов тока не появится: либо сработает УЗО, либо сгорят резисторы на входах токовых трансформаторов.<br />
'''<br />
===Подключение интерфейсной части===<br />
Счетчик подключается к контроллеру через разъемы A и B RS-485. Питание интерфейсной части может подаваться непосредственно от контроллера (Клеммы Gnd (-) и Vout (+)), либо от отдельного источника питания — в этом случае линии GND контроллера и источника питания рекомендуется объединить.<br />
<br />
===Подключение высоковольтной части===<br />
К разъемам высоковольтной части счетчика подаются одна фазы, нейтраль и защитное заземление. При подключении защитное заземление (PE) и нейтраль (N) должны подключаться первыми, во избежание поражения электрическим током (см. предупреждение выше).<br />
<br />
===Подключение токовых трансформаторов===<br />
<br />
При подключении токовых трансформаторов следует верно расположить их на фазовых проводниках и правильно подключить выводы к разъемам счетчика. Также важно, чтобы каждый токовый трансформатор был подключен к проводнику той же фазы, которая подается на счетчик.<br />
К токовым входам счетчика со знаком "минус" подключаются черные провода трансформаторов тока, а ко входам со знаком "плюс" -- белые (см. рисунок "Пример схемы подключения счётчика WB-MAP6S").<br />
В счетчиках-измерителях, прошедших процедуру предварительной калибровки, к каждому токовому каналу подключается индивидуально подобранный токовый трансформатор. Трансформаторы имеют подписи с указанием номера канала.<br />
<br />
==== Направление подключения токовых трансформаторов ====<br />
<br />
[[File:Current_Transformer_with_Wire.png |400px|thumb|right|Трансформатор тока с проходящим через него фазовым проводником; стрелка направлена в сторону подключенной нагрузки. Трансформатор показан в открытом состоянии.]]<br />
<br />
<br />
При подключении токового трансформатора следует верно расположить его на проводнике и правильно подключить выводы к счетчику. Расположение токового трансформатора на фазовом проводнике, ведущем к нагрузке, показано стрелкой, направленной к нагрузке. <br />
Здесь следует сделать оговорку, что речь идет о тех сетях, подключенных к счетчику, которые потребляют, а не генерируют энергию. К примеру, некоторые модели инверторов, обеспечивающих дополнительное питание нагрузки потребителей от солнечных батарей или ветряных генераторов, могут отдавать в электросеть избыточную энергию. В качестве генераторов энергии могут выступать и электродвигатели, вращаемые внешними силами.<br />
<br />
Таким образом, если в сети нет внутренних источников электроэнергии, а направление установки токового трансформатора выбрано верно, то активная мощность, где установлен трансформатор, будет иметь положительное значение, если неверно — то отрицательное. Если в сети генерируется электроэнергия, то такая оценка будет неинформативной.<br />
<br />
== Индикация ==<br />
[[File:MAP6S-LAMP.JPG|250px|thumb|left|Индикаторы]]<br />
<br />
Счетчик имеет 3 светодиодных индикатора: <br />
* S — зеленый индикатор статуса, мигает при обмене данными по Modbus<br />
* CF1, CF2 — красные индикаторы потребляемой суммарной энергии по трем каналам (учитывается только активная энергия). Мигание индикаторов означает потребление электроэнергии: 3200 импульсов соответствуют 1 кВт·ч.<br />
<br />
== Представление в web-интерфейсе ==<br />
Полный список названий параметров, отображаемых в web-интерфейсе приводится на странице [[Power Meter WB-MAP6S Measuring Parameters|Счетчик WB-MAP6S: измеряемые параметры и погрешности, их названия в веб-интерфейсе Wiren Board]]<br />
<br />
== Описание Modbus-регистров ==<br />
Счетчик поддерживает большое количество Modbus-регистров, которые хранят значения измеряемых и вычисляемых величин, а также регистры управления счетчиком. <br />
<br />
Таблицу регистров, описывающих измеряемые величины, можно найти на странице [[Power_Meter_WB-MAP6S_Measuring_Registers|Многоканальный счётчик электроэнергии WB-MAP6S: таблица Modbus-регистров измеряемых и вычисляемых величин]]. <br />
<br />
Карта регистров совпадает с таковой для MAP12H со следующими отличиями:<br />
<br />
* доступно два канала, а не четыре;<br />
* напряжения для всех трёх фаз канала одинаковые;<br />
* фазовые углы сдвига напряжения между фазами равны 0 для всех фаз.<br />
<br />
Таблица управляющих регистров приведена на странице [[Power_Meter_WB-MAP6S_Control_Registers|Многоканальный счётчик электроэнергии WB-MAP6S: таблица управляющих Modbus-регистров]].<br />
<br />
<br />
== Изображения и чертежи устройства ==<br />
{{Wbincludes:WBPictures|1}}</div>Xenols