Безпека і криптографія / крок 03
Що захищає твої дані й гроші від хакерів? Асиметричне шифрування та цифровий підпис
Про що це відео
Теза автора: одна пара понять — асиметричне шифрування і цифровий підпис — пояснює, як працюють HTTPS, вхід по SSH-ключу, ProtonMail/PGP, підпис у «Дії» («дієпідпис») та банківські підписи, холодні блокчейн-гаманці, JWT і Google Authenticator. Він одразу застерігає, що не є криптографом, і цитує Брюса Шнаєра — будь-хто здатен придумати шифр, який сам не зможе зламати, — тому ніколи не пишіть власну криптографію: розумійте концепції і користуйтеся стандартними бібліотеками. Він проходить логіку на дошці (симетричне = один спільний секрет; асиметричне = пара публічний/приватний, де ділитися приватним ключем не потрібно ніколи), показує, чому шифрувати приватним ключем безглуздо задля секретності, але саме це — механізм підпису (на практиці підписують хеш/контрольну суму документа, а не сам документ), демонструє справжню автентифікацію по SSH-ключу на свіжому сервері DigitalOcean (ssh -v, authorized_keys, челендж сервера з випадковим рядком) і завершує робочими прикладами на Node.js crypto на GitHub: підпис/перевірка та шифрування/розшифрування RSA, підписи на еліптичних кривих і AES-256-CBC з вектором ініціалізації — з ілюстрацією знаменитим пінгвіном, зашифрованим у режимі ECB.
Головне
- У RSA два ключі взаємозамінні за властивостями, але шифрування приватним ключем не дає конфіденційності (публічний ключ є в усіх) — саме цей «марний» напрямок і експлуатує цифровий підпис: зашифруй хеш документа приватним ключем — і будь-хто зможе перевірити автентичність та цілісність публічним.
- Асиметричні шифри у ~100–1000 разів повільніші за симетричні, тому HTTPS, PGP тощо шифрують самі дані симетрично, а пару ключів використовують лише щоб встановити симетричний ключ; сучасний HTTPS перейшов від обміну ключами через RSA до Діффі–Геллмана заради Perfect Forward Secrecy, а еліптичні криві (без RSA-подібного шифрування, лише DH + підписи) дають ту саму стійкість із коротшими ключами.
- «Слон у кімнаті», якого він залишає для майбутнього відео про HTTPS: доставлення самого публічного ключа. Man-in-the-middle, який підмінить публічний ключ на свій, зводить усе нанівець — саме тому існують сертифікати, центри сертифікації та ієрархія CA.
- Підписи JWT бувають симетричні (HMAC зі спільним секретом — видає і перевіряє одна й та сама сторона) або асиметричні — його приклад із мікросервісами: підписуй приватним ключем, і будь-який інший сервіс зможе перевіряти токени, маючи лише публічний ключ, а не секрет.
- Google Authenticator (TOTP) — це просто HMAC від спільного секрету плюс поточний інтервал Unix-часу (наприклад, 30-секундні вікна) — тому телефон із збитим годинником генерує недійсні одноразові коди.
- Холодні криптогаманці: приватний ключ живе на офлайн-машині; там підписуєш файл транзакції, переносиш його на флешці на машину з інтернетом і відправляєш у блокчейн — підписану транзакцію не страшно показати світові, а біткоїн-адреса — це, по суті, хеш публічного ключа.
- Байка з SSH-демо: він неодноразово просив розробників «надішли мені свій ключ, додам тебе на сервер» — і отримував приватний ключ. Ніколи не діліться приватним ключем — він еквівалентний паролю.
- Випадковість — теж частина безпеки:
Math.random()у JavaScript робить криптографію вразливою (використовуйтеcrypto.getRandomValues); він згадує оновлення Windows, яке принесло благословенний NIST генератор випадкових чисел, що його широко вважають бекдором NSA, — після хвилі обурення його замінили в наступному оновленні.