CryptodevATECCx08 Auth: различия между версиями
Xenols (обсуждение | вклад) |
Xenols (обсуждение | вклад) |
||
Строка 32: | Строка 32: | ||
Для этого сгенерируем ключевую пару: | Для этого сгенерируем ключевую пару: | ||
<pre>openssl genrsa -out ca.key 2048<pre> | <pre>openssl genrsa -out ca.key 2048</pre> | ||
И сертификат нашего '''CA''': | И сертификат нашего '''CA''': | ||
Строка 113: | Строка 113: | ||
Цифровая подпись гарантирует, что никакая часть сертификата не может быть незаметно изменена. В случае изменения проверка публичным | Цифровая подпись гарантирует, что никакая часть сертификата не может быть незаметно изменена. В случае изменения проверка публичным | ||
ключом '''CA''' даст ошибку. | ключом '''CA''' даст ошибку. | ||
<pre> | |||
openssl x509 -text -noout -in ca.crt | |||
Certificate: | |||
Data: | |||
Version: 3 (0x2) | |||
Serial Number: | |||
d9:e0:91:e7:d0:27:02:db | |||
Signature Algorithm: sha256WithRSAEncryption | |||
Issuer: CN = MY CA | |||
Validity | |||
Not Before: Feb 4 14:30:01 2019 GMT | |||
Not After : Feb 1 14:30:01 2029 GMT | |||
Subject: CN = MY CA | |||
Subject Public Key Info: | |||
Public Key Algorithm: rsaEncryption | |||
Public-Key: (2048 bit) | |||
Modulus: | |||
00:c8:5e:02:b8:55:e5:42:97:f7:c6:53:61:d3:df: | |||
66:bf:05:dd:7a:0c:61:a4:68:36:23:3f:3b:c7:83: | |||
ec:47:9b:5a:ed:78:8a:5b:f1:5f:88:3d:36:f2:3e: | |||
7b:84:9e:1b:e5:87:bf:3b:00:33:36:1c:0b:3a:16: | |||
2f:8d:be:0e:a4:9e:25:73:4d:93:8a:47:74:29:65: | |||
0e:4e:ea:44:fd:c4:c0:bf:fa:bc:11:d5:93:43:e2: | |||
65:18:bb:f7:e5:fc:16:8c:f9:11:97:76:2c:bb:cb: | |||
c0:94:7e:78:12:20:c9:8a:68:29:c1:e8:af:7e:d7: | |||
63:6e:a3:57:79:c9:b3:a8:8c:a3:2d:3e:15:1a:25: | |||
ea:f1:50:fc:ea:93:8f:14:5f:34:61:07:a9:dc:24: | |||
b8:11:de:9c:17:13:03:19:0d:0c:a3:e8:10:31:50: | |||
82:5b:cb:0e:26:d5:b1:fe:df:c3:f6:f9:e4:0f:b1: | |||
24:40:f2:8d:95:d5:ea:34:b3:27:a1:87:76:9d:f2: | |||
65:74:d5:40:47:dd:a1:32:46:c3:37:ec:a5:b3:09: | |||
30:73:99:d1:9c:bb:a8:05:61:2a:56:89:32:5e:c0: | |||
5d:1d:b6:a6:b6:74:17:be:74:69:9c:b0:e3:bc:b4: | |||
f9:96:6d:aa:60:ae:70:d1:ee:07:e5:2c:5d:0a:af: | |||
ce:b3 | |||
Exponent: 65537 (0x10001) | |||
X509v3 extensions: | |||
X509v3 Subject Key Identifier: | |||
53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14 | |||
X509v3 Authority Key Identifier: | |||
keyid:53:4B:6D:7A:1A:1F:F8:BE:3F:59:64:70:2B:31:2F:7A:7F:2A:6B:14 | |||
X509v3 Basic Constraints: critical | |||
CA:TRUE | |||
Signature Algorithm: sha256WithRSAEncryption | |||
30:c2:f3:e0:96:51:7d:13:be:06:1d:40:06:70:b8:36:e9:46: | |||
81:64:0c:f0:e7:69:6f:31:2c:e1:86:df:f8:ad:b2:84:6e:90: | |||
4a:38:48:7d:ae:92:a5:71:40:c8:8e:0f:7e:67:e5:66:e7:70: | |||
4d:52:92:fa:a6:54:45:3b:a6:b9:b3:f4:35:ad:1c:6e:6e:15: | |||
06:81:ef:13:54:80:89:2e:7d:75:06:22:59:89:44:a9:ad:25: | |||
30:6c:02:e1:3b:2e:e2:bc:46:90:d1:a5:00:eb:87:57:60:a4: | |||
cf:e0:03:4a:b5:32:c4:dc:c7:e3:34:d4:c8:af:e3:ce:20:8c: | |||
c4:7f:f0:b8:72:d7:65:3b:38:be:2b:b1:d0:4e:9e:e2:52:32: | |||
41:fe:22:d2:7c:13:60:fe:4a:13:4b:c5:09:f0:00:89:32:22: | |||
47:4d:2c:a1:21:8e:b2:7d:0f:1a:10:f5:94:ee:fb:18:d3:15: | |||
f1:9e:70:89:73:c4:41:71:0e:92:22:9c:18:ef:0b:b1:7c:42: | |||
41:e7:9f:e7:82:d5:db:f3:60:d3:2f:2a:86:e4:0c:c0:4c:0c: | |||
17:12:ec:e4:37:96:dc:2d:01:00:22:ac:b5:33:6b:97:41:d7: | |||
37:e5:75:fa:c9:6b:00:2a:d8:87:0f:9e:f3:aa:c5:23:4e:60: | |||
02:a9:5b:eb | |||
</pre> | |||
Видим, что сертификат подписан сам своим-же приватным ключом (Issuer: CN = MY CA, Subject: CN = MY CA) | |||
и выписан на 10 лет: начная с "Feb 4 14:30:01 2019 GMT" (для этого мы указывали -days 3650 в команде подписи) | |||
Таким образом цепочка доверия (проверки) выстраивается следующим образом: | |||
Сертификат устройства подписан сертификатом CA и может быть им проверен: | |||
<pre> | |||
openssl verify -CAfile ca.crt device_AP6V5MDG.crt | |||
device_AP6V5MDG.crt: OK | |||
</pre> | |||
Ну а сам сертификат подписан "собой": | |||
<pre> | |||
openssl verify -CAfile ca.crt ca.crt | |||
ca.crt: OK | |||
</pre> | |||
''' | |||
Настройка nginx. | |||
Допустим в интернете есть сервер, который должен обрабатывать запросы только от устройств обладающих сертификатами, | |||
выписанными нашим CA. | |||
Для включения такой проверки в конфигурационном файле nginx необходимо в секции http или server прописать следующие строчки: | |||
<pre> | |||
ssl_client_certificate ca.crt; | |||
ssl_verify_client on; | |||
</pre> | |||
Теперь nginx будет требовать от клиента сертификат, который должен проходить проверку с помощью ca.crt, иначе сервер | |||
вернет клиенту ошибку 400: | |||
<pre> | |||
curl https://example.com | |||
<html> | |||
<head><title>400 No required SSL certificate was sent</title></head> | |||
<body bgcolor="white"> | |||
<center><h1>400 Bad Request</h1></center> | |||
<center>No required SSL certificate was sent</center> | |||
<hr><center>nginx/1.14.0 (Ubuntu)</center> | |||
</body> | |||
</html> | |||
</pre> | |||
Теперь сделаем так, чтобы HTTP запросы с контроллера WB проходили данную проверку. | |||
Для простоты будем использовать nginx и на клиентской стороне. Это даст возможность работать | |||
с защищенными серверами клиентам не умеющим делать SSL соединения. | |||
Для начала создадим на неиспользуемом локальном порту http сервер, который будет делать | |||
всю https "магию" за нас: | |||
<pre> | |||
server { | |||
listen 8080; | |||
location / { | |||
proxy_pass https://example.com; | |||
proxy_ssl_name example.com; | |||
proxy_ssl_server_name on; | |||
proxy_ssl_certificate device_AP6V5MDG.crt; | |||
proxy_ssl_certificate_key engine:ateccx08:ATECCx08:00:04:C0:00; | |||
} | |||
} | |||
</pre> | |||
Добавим пользователя www-data в группу i2c для доступа к криптоустройству: | |||
<pre> | |||
usermod -G www-data | |||
</pre> | |||
Выполним команду '''service nginx restart''' для обновления конфигурации. | |||
Теперь при обращении по http на локальный порт 8080 зашифрованные запросы с аутентификационной | |||
информацией будут отправлятся на сервер example.com. | |||
<pre> | |||
curl localhost:8080/ | |||
<html> | |||
<body> | |||
EXAMPLE.COM | |||
</body> | |||
</html> | |||
</pre> |