There's no secret that over the past year, Apple has considered removing the Lightning port from iPhones and accessories. Before the presentation, there were many discussions among Apple's sectarians.
Should the European Union influence major Silicon Valley companies at all? Was Lightning the best connector in the world? Is Type-C evil? And many other strange questions.
Most of the arguments in favor of a proprietary connector are sheer sectarianism. I want to break down a bit why Lightning should have disappeared a long time ago.
Peripherals
Let's start with the fact that Lightning was a good form factor for its time. At that time, there was no Type-C specification, but there was an awful Micro USB, which can still sometimes be found in devices because it's cheap. Besides being one-sided, it constantly broke.
Now almost all technology is released with a Type-C connector. One cable is enough to charge a computer, connect a monitor Thunderbolt cord is needed, PlayStation or Xbox controller, headphones (except those from Apple, of course), iPad, or camera.
Currently, only the iPhone, AirPods, keyboard, and mouse require their proprietary wire.
It also works the other way around. You can't just connect an SSD to an iPhone to transfer a 30-minute 4K video. You can't directly connect a camera to transfer video from it to your phone. You can't connect your phone to a TV if it doesn't support AirPlay or if the wireless network quality is poor.
Almost any case of connecting something to an iPhone ends with it being impossible to do so. Meanwhile, I've been able to do all this with my iPad for a couple of years.
Type-C Is Unreliable and Some Different Cords
I'll just remind you that Type-C is just a form factor for USB, which can support different specifications. It might not even transfer data, just provide power to the device.
Lightning is the same. But the joke is that it only supports the outdated and slow USB 2.0. And there are also Lightning cords from China that can only charge the phone.
Myths about Type-C being unreliable compared to Lighting are mostly nonsense. The pins in Lighting can break just as easily, and the connector itself oxidizes over time. If it's somewhat more reliable, it doesn't outweigh all the benefits of a universal connector.
To cover 99% of the use cases of any Type-C connector, buy quality cords. A good cable isn't cheap, and the price starts at $40. A good cable usually has a lightning icon, indicating that the cord supports Thunderbolt. Such cords can even be used to connect monitors.
The only reason why Lighting hasn't disappeared yet is money. Apple made money on this connector; manufacturers must pay Apple to do something with this connector.
Just a reminder of the glorious times when phones didn't have a 3.5mm jack and headphones from various manufacturers were tightly tied to the device because of a custom connector. Sounds cool? Apple still sells headphones with Lightning when all other wired headphones are with Type-C. Just like 20 years ago.
UPD: I wrote this post before the presentation and unexpectedly guessed all the points that were made. Now they will be selling EarPods with a Type-C connector. Are you still against EU regulation?
As you can guess, I'm a fan of computers and Apple. One morning, we thought about where to go, and Kate read about the Apple museum in Warsaw. My first thought was something like oh-my.
This museum is the largest in the World. I think it's a fun fact. Steve Wozniak – one of the founders of Apple – has Polish roots. The family name also hints about it.
Cześć, Hello, Bonjour! The ticket costs $12.
The museum is in Fabryka Norblina in the center of Warsaw. It's a factory with 200 years of history. There are more than 1600 exhibits related to the history of Apple. Do you know about Apple printers or cameras?
Apple I
Apple I was the first computer developed by Apple in 1976. The introductory price was $666.66. There are no more than 50 computers in the world nowadays. If you are lucky enough, you can find one at the auction for $500.000.
It's a replica of the original computer, but you can see real Wozniak's sign on the user manual and the motherboard.
Apple II and friends
Apple II is a legend in the computer world because it's one of the first personal computers and the most produced and cloned computer.
The series was started in 1978 and discounted in 1993. There are many-many modifications and many-many clones. Some sources say that around 200 clone models were produced.
Almost modern Macs
Zoomers don't know about them. Boomers say that they were the best computers and the grass was green. For me, it's just computers.
I didn't know about enterprise solutions like Workgroup Server before. The series of Workgroup Servers was started in 1993 and discounted in 2003. Also, "Studio Display" is reused title from 1999.
Notebooks
Newton, colorful iBook, PowerBook? Black MacBook from plastic?
Duo Dock II is one of the most strange devices, in my opinion. The docking station turns a connected PowerBook Duo into a full-featured desktop Macintosh.
Printers
Apple produced printers and print paper from the 1980s to the end 1990s. They can be divided into three groups: dot matrix, laser, and thermal inkjet.
Some weird things from Apple
Analog Apple Watch, digital camera QuickTake, video conference camera, the repair suitcase. Wow!
Posters
Software, guides, and other boxes
Do you remember software boxes, CDs, and tapes? I think it's a kind of forgotten art. Some of the examples were very unexpected for me. Some of them look very fresh even today.
Bonus videos
I played with old-school iMacs produced at the start of the 2000s. Sometimes I see opinions like old macOS was better and faster. So, you can check the genie effect on the original iMac PowerPC!
Really don't understand why modern OS are so silent. Just listen to these sounds. I think they are fun and cute.
Conclusion
Must see it in Warsaw. It's a nice place if you love the history of computers or are a tech lover. Exhibition changes time-to-time. I visited the museum at the end of 2022.
Artykul is an app that allows you to read your favorite sites in one place without ads, clutter, and algorithmic newsfeeds. I'm excited to announce the app is available on the App Store for iOS, iPadOS, and macOS!
We have been developing the app since March 2021. The first iteration worked on our servers, but we abandoned this decision and rewrote the backend and the client from scratch. The second iteration works on the device in your pocket.
You can add any website that has RSS or Atom feed. RSS is simple, open, and time-proven technology. You can take back control of your news feed. Unlike any other reader, Artykul uses RSS or Atom only for searching links, not content. In the future, we can add support for sites without feeds.
We developed the best-in-class Article Reader. And you can customize it: font, size, and color theme. All articles in Artykul are available offline. The reader also remembers a position where you stop reading.
One small surprise for developers is Artykul Instructions. It's a small JSON-based format that describes web pages and their content. With the help of instructions, developers can modify web pages before converting and provide more meta information from the page. Feel free to try it!
Artykul for macOS
You can turn on push notifications for new articles from favorite sites. Our backend checks sites and notifies you when found something new.
We have implemented so many features and a million more well on the way. I can speak about the app all day. A picture is worth a thousand words, better try it yourself.
Folders
Bookmarks
Favorites
Full-Text Search
Unread indicator
Mark as read on the scroll
Custom feed settings for images and cell size limiting
Gesture navigation and full-screen reader
Folders with custom icons
Custom site names
Storage settings
4 themes for the reader
Discover
App tint color
OPML import and export
And more-more-more...
We also developed widgets for sites. You can see it at the bottom of the screen if you view this page from an Apple device. Soon we will publish documentation for web developers and site owners. You will be able to integrate your blog or news site with Artykul in 1 minute.
Oh, and today you can read my blog in my app! Ecosystem! I'm also starting to blog in English. It's my first note 🥹
"Вход через Apple" был представлен в 2019 году и стал обязательным для всех приложений, которые используют авторизацию через социальные сети или внешние сервисы.
Я реализовывал функцию несколько раз и набил пару шишек на ней. Перед тем, как её реализовывать, хорошо подумайте, потому что самый главный вывод, который я сделал: не связывайтесь с авторизацией через Apple.
За неё нужно платить 100 долларов в год.
API очень запутанное, а отсутствие некоторых методов накладывает на архитектуру серверного приложения определённые ограничения.
Сложно тестировать.
iOS приложение
Здесь нет ничего сложного, но есть некоторые моменты, на которые стоит обратить внимание. Для начала добавьте в настройках проекта одноименное разрешение.
В 2022 году при авторизации можно попросить полное имя и электронную почту.
Первый важный момент: запрашиваемые данные передаются лишь однажды при первом входе, поэтому обязательно сохраните их в Keychain. Если ваш сервер или сеть отвалится и вы не сможете с первого раза отправить эти данные, то боюсь, что ваш пользователь больше не сможет войти.
Для работы с Keychain я использую KeychainWrapper. Репозиторий давно не обновлялся, но и в API ничего не менялось.
Если вы всё-таки запрашивали данные, но потеряли их, то вход можно сбросить через настройки: Settings → Apple ID → Password & Security → Apps Using Apple ID → Stop using Apple ID.
Второй важный момент: это не работает в симуляторе. В iOS 16 может починили, но я не проверял.
Третий важный момент: в Catalyst кнопка из SwiftUI не работает и приложение просто падает. Багу сто лет. Может быть его уже исправили, но я не проверял.
В SwiftUI добавить кнопку очень просто. Не забудьте импортировать AuthenticationServices.
SignInWithAppleButton(.continue, onRequest: { request in
request.requestedScopes = [.email, .fullName]
}, onCompletion: { result in
switch result {
case .success(let auth):
// handle it
case .failure(let error):
// ¯\_(ツ)_/¯
print(error)
}
})
В UIKit тоже ничего сложного нет, но придётся написать чуть больше кода. Создать фирменную кнопку можно примерно вот так.
Identity Token содержит всю самую важную информацию: уникальный идентификатор пользователя, email и fullName.
Серверная часть
Если для вашего языка программирования есть хорошая библиотека для валидации токенов от Apple, то поздравляю, можете её взять и использовать. Скорее всего, её нет.
Перед тем, как вы сможете валидировать токены, необходимо получить ваш приватный ключ в Apple Developer. Если вы отправляете пуши, то у вас он скорее всего есть.
Apple Developer → Certificates, Identifiers & Profiles → Keys. Не забудьте включить сервис Sign In with Apple.
Сохраните ключ в безопасное место и не делайте хардкод. Вместе с ключом вам нужно держать рядом Key ID, Team ID и Bundle ID вашего приложения.
Генерируем токен для сервера
Перед этим шагом поищите библиотеку для JWT, если у вас её ещё нет.
Он нужен для того, чтобы отправлять запросы на сервера Apple. Представляет из себя обычный JSON Web Token (JWT) в котором указаны Team ID и Bundle ID. Подписать его нужно вашим приватным ключом, который вы скачали у Apple.
В документации более подробно расписано про все поля. Ниже пример пейлоуда на Go, а вот пример генерации на питоне.
Для подписи используйте ES256.
type SecretKeyPayload struct {
Iss string `json:"iss"`
Iat int64 `json:"iat"`
Exp int64 `json:"exp"`
Aud string `json:"aud"`
Sub string `json:"sub"`
}
Проверяем Identity Token
Сначала нужно скачать JSON Web Key (JWK) от Apple, которыми подписываются токены для авторизации. Адрес с ключами ниже.
https://appleid.apple.com/auth/keys
Не все библиотеки для JWT поддерживают JWK, но в этом нет ничего страшного. JWK представляет из себя просто массив ключей. Достаточно разобрать заголовок из JWT и найти публичный ключ у которого такой же kid.
Учитывайте, что ключи очень часто обновляются. Количество ключей и они сами постоянно меняются.
identityToken, который прислал нам iOS клиент, представляет из себя как раз таки JWT, который подписан одним из этих ключей.
Не забудьте дополнительно проверить следующие поля:
exp меньше текущего времени в UNIX.
iss равен https://appleid.apple.com.
aud равен нашему Bundle ID.
Генерируем Refresh Token
На этом шаге нам пригодится приватный ключ сервера, который мы уже сгенерировали и подписали ранее. Более подробная документация доступна на сайте Apple.
https://appleid.apple.com/auth/token
На этот адрес отправляем запрос с следующей формдатой:
client_id с идентификатором приложения.
client_secret с серверным токеном.
grant_type с строкой authorization_code.
code с authorizationCode, который нам прислало iOS приложение.
В ответ должен прилететь JSON с следующей структурой. Не забудьте проверить HTTP статус, он должен быть 200.
В ответе можно найти id_token, это новый железобетонный identityToken, который уже точно можно использовать внутри приложения.
А что дальше?
Можно добавить нового пользователя в систему и сгенерировать свой собственный токен, чтобы отдать его клиенту. Вы же не хотите такой ерундой заниматься каждый раз на эппловых токенах?
Пятый важный момент: обязательно сохраните в базу данных refresh_token и access_token. Желательно с привязкой к вашим внутренним сессиям.
Зачем это нужно? Я не знаю, спросите у Тима Кука или напишите петицию, что у лучших инженеров какое-то абсолютно дебильное API с ненужными действиями, потому что вы ничего не сможете сделать с этими токенами, кроме как отозвать или провалидировать.
Обновляем Access Token
В документации написано, что делать это нужно раз в сутки.
Адрес совпадает с генерацией, но немного меняются данные:
grant_type с строкой refresh_token.
refresh_token с собственно токеном, который мы получили.
Отзываем токены
Видимо, их стоит отзывать, когда пользователь разлогинивается в приложении. А ещё нужно отозвать все токены, которые нам выдал Apple, если пользователь решил удалить аккаунт в приложении. Сделать это можно только по одному за раз.
https://appleid.apple.com/auth/revoke
На этот адрес отправляем запрос с следующей формдатой:
client_id с идентификатором приложения.
client_secret с серверным токеном.
token_type_hint с строкой refresh_token или access_token.
token с самим токеном.
В случае успеха возвращается 200-ый код с пустым телом. В общем, на ответ можно просто забить.
Заключение
Я бы хотел написать, что авторизация через Apple – это круто, но нет.
С 2019 года здесь есть какой-то бессмысленный набор токенов, который нужно валидировать и хранить. Зачем нужен access_token?
Почему нельзя в любой момент получить электронную почту?
Зачем делать столько лишних запросов на подтверждение, если ваши сервера сами подписывают Identity Token?
Почему они не сделали метод для отзыва всех токенов за раз? Даже писал репорт им, что это тупость откровенная без такого метода жить, но мне никто не ответил.
С 2022 года, если ты ещё неправильно хранишь и отзываешь эти токены, то нарушаешь гайдлайны App Store.
Самый главные подводные камни:
Сохраняйте email и fullName на клиенте, пока точно не будете уверены, что регистрация была успешной.
Сохраняйте токены вместе с вашей внутренней сессией.
Сквозное шифрование, менеджеры паролей, блокчейны, секретные чаты в телеграме и вообще, что это всё значит в этих новостных заголовках, я уже ничего не понимаю, всем пока, я в лес.
Если у вас возникало такое чувство, то сейчас попытаюсь объяснить основы криптографии прямо на пальцах, чтобы больше не было страшно. Современная криптография в вакууме – это сложная штука с кучей математики и магии, но в математику не нужно вникать, чтобы понять, как это работает.
Терминология
Она очень странная и непривычная: таких слов в обычной жизни не встретишь. Какие-то ключи, кодирования, шифрования, декодирования, хэши, эллиптические кривые, ааа.
Зануды будут сразу вас поправлять и морщиться, когда вы перепутаете кодирование с шифрованием, но теперь вы будете точно знать, что кодирование это про алкоголиков – это преобразование фотографий котиков в формат, подходящий для обработки другой программой, а шифрование, чтобы никто другой больше не смог посмотреть котиков, пока они передаются или хранятся. Короче, кодирование – это не про безопасность.
Кодирование и декодирование не предполагает наличие какого-то секрета или пароля, а шифрование и дешифрование предполагает. Еще помните, что хэширование – это поезд в одну сторону. Хэш вообще нельзя расшифровать.
Хэширование
Хэш – это результат хэш-функции или операции хэширования. Хэш от английского hash – беспорядок, путаница. В общем, это какое-то беспорядочное значение фиксированного размера, которое получается от некоторого вполне порядочного любого размера. Хэширование рядом с шифрованием, но не имеет к нему прямого отношения.
Вот например у вас есть фотография котика и у вашего друга есть такая же фотография котика, но нам нужно точно удостовериться, что у нас точно одинаковые котики.
Простой вариант в том, чтобы просто скинуть друг-другу эти фотографии и сравнить их 1 в 1, но что если у нас 4K HDR видео котика на один час в несколько десятков гигабайтов? Каждый раз как-то скидывать друг-другу это видео? А если видео ломается при пересылке или лучший файлообменник мессенджер, в котором мы это делаем, подменяет кадры с котиком?
Хэш-функция придёт на помощь и превратит нашего котика в бессмысленную строку! Есть очень много разных функций для хэширования, например, MD5, SHA-1 и SHA-2.
Наглядное превращение котика в 64 символа случайного текста.
С помощью хэширования нам уже не нужно пересылать всего котика, чтобы уникально его идентифицировать, а достаточно одной короткой строки, которую можно продиктовать хоть по телефону.
Но это всё равно не решает проблему с тем, что котика могут подменить, а по телефону с помощью дипфейков робот зачитает нам неверный хэш, поэтому мы пойдём немного дальше: придумаем какой-то секрет, который будете знать только вы, ваш друг и никто больше.
Упрощённая схема того, как работает HMAC.
Вы прохэшируете вашего котика, добавите этот секрет к хэшу котика и потом захэшируете его ещё раз. Примерно в этом смысл ещё одного страшного термина – HMAC. С поправкой на то, что HMAC работает чуть-чуть сложнее, чтобы уменьшить количество возможных атак на ваш котообмен.
HMAC – hash-based message authentication code.
Теперь при получении фотки котика, вы, зная секрет, точно сможете проверить, что этого котика отправил ваш друг, а не кто-то посторонний. Достаточно проделать операцию повторно и сравнить два получившихся хэша.
Если вы любите торренты, то видели, что в раздачах указывают всякие контрольные суммы или хэши. Они же указываются иногда при скачивании всяких программ с всяких сайтов. С их помощью можно точно узнать то, что файл не сломался при передаче по сети или его никто не подменил в процессе загрузки.
Ещё одно применение хэш-функций – это хранение паролей. Вы слышали истории про утечки баз данных сайтов или сами попадали в ситуацию, когда какой-то индюк из Индии в 3 часа ночи залогинился в вашем аккаунте в Инстаграм?
Скорее всего, это произошло потому, что вы вводили одинаковый пароль на разных сайтах и на одном из сайтов разработчик не захэшировал ваш пароль перед тем, как положить в базу данных, а эту базу данных потом украли.
А вот если бы разработчик сайта захэшировал ваш пароль, то такой ситуации бы не случилось, ведь пароль в чистом виде остался бы неизвестным.
Кстати, это одна из самых главных причин использовать менеджеры паролей с уникальными паролями для всех сайтов. Придумывание паролей по маске или что-то такое спасёт вас только от автоматизированных атак, но если живой человек увидит пароль superpassword_google.com, то, наверное, он что-то заподозрит.
В идеальном мире вероятность получить одинаковый хэш для разных входных данных стремится к нулю. Если двум входным значениям соответствует одинаковое выходное, то это значит, что произошла коллизия.
Теоритически злой пёсель выдал такой же хэш, как и котик!
Особенно опасно и страшно всем вокруг становится, когда кто-то внезапно научился подбирать за разумное время к одному входному значению для хэш функции другое, которое даст такой же хэш. Теоретически они все ломаются простым перебором за сотни и тысячи лет.
Такое случается с алгоритмами достаточно часто. Например, SHA-1 уже можно сломать за копейки. Такая же ситуация с MD5 уже много лет.
Значит ли это, что эти алгоритмы уже прямо совсем нельзя использовать? В криптографических задачах точно не стоит, но, чтобы сравнивать котиков в условиях, когда вопрос не о трёхзначных циферках, вполне себе можно.
Симметричное шифрование
У симметричных алгоритмов шифрования используется один ключ для шифрования и дешифрования. Скорее всего, вы уже что-то шифровали в своей жизни и делали это ещё в школе.
Например, применяли шифр Цезаря или шифр сдвига, то есть брали алфавит и сдвигали его на некоторое количество символов. Ключ в данном случае – это количество символов на которое сдвинут алфавит. Такой шифр можно взломать на листке бумаги за несколько минут, попробуйте.
Расшифруйте секретное кодовое слово.
В интернетах обычно используется алгоритм AES с длиной ключа 128, 196 или 256 бит. Чем длиннее ключ, тем круче. Раньше использовали DES или 3DES (в старых системах до сих пор используют).
Современные алгоритмы шифрования – это чисто про математику и магию. Основная идея в том, чтобы из обычного сообщения получить набор кракозябр, который статистически не связан с оригинальным.
Сами по себе современные алгоритмы в вакууме можно считать очень безопасными. AES-256 используют для банковских операций и им даже шифруют всякие гостайны в штатах.
Откуда тогда эти истории про взломы всего, чего только можно, ведь всё же зашифровано? Но тут и секрет: обычно шифрование не взламывают.
Все истории начинаются с этих простых житейских проблем, которые начнутся, когда вы решите отправить нашего котика и зашифровать его с помощью AES.
Сгенерировать ключ.
Передать этот ключ собеседнику, чтобы его не узнал кто-то ещё.
Ключ нужно как-то безопасно хранить.
А если потом всё же кто-то узнал этот ключ, нужно проделать это всё повторно.
Ключ всё таки иногда нужно обновлять, чтобы, если украдут один ключ, не украли все фотографии котиков.
Вероятность факапа на каждом этапе очень высокая.
А в чём проблема сгенерировать случайный ключ? Ну хотя бы в том, что компьютеры разрабатывают так, чтобы они были предсказуемыми. Мы же не хотим, чтобы два плюс два в айфоне давало каждый раз новый результат.
Конечно, в современных приложениях и операционных системах придумают всякие хитрые способы для генерации случайных чисел, а в компьютеры встраивают аппаратные генераторы, но если представить, что источник случайных цифр выдаёт их неслучайным образом, то AES уже не поможет.
Офис CloudFlare с лава-лампами, которые используются для генерации случайных чисел.
Свежий показательный пример, когда всё поломалося при генерации случайных чисел на процессорах Intel.
Если кратко, то результат работы генератора случайных чисел хранился в общем буфере для всех ядер. Плохое приложение могло узнать случайные байты, которые запрашивало себе другое приложение.
Ну то есть вы сгенерировали ключ, а другое приложение уже знает этот ключ. И никто ничего не заметил, никакого взлома шифрования, шпионских устройств и Джеймса Бонда.
Ну а в чём проблема передать ключ? Никакой проблемы нет, если у вас есть возможность встретиться лично. А вот если вы живёте в разных частях планеты? Передавать ключ шифрования по общедоступным каналам, это не самая лучшая идея.
А если вы уже можете встретиться лично и передать безопасно ключ, то зачем вам тогда вообще этим заниматься, если секреты можно обсудить лично.
Так а с хранением что? Положить ключ на рабочий стол или в любое другое место можно, но к нему могут иметь доступ другие приложения, которые могут его и украсть. Ну и вы же слышали про вирусы?
А ещё внезапно ваш ключ засинхронизируется каким-то модным приложением в эти облака, ваш пароль от аккаунта куда-то утечёт и его взломают. Кто-то бесплатно получит ваши ключи.
Но есть и хорошие новости. Производители компьютеров придумывают целые аппаратные хранилища исключительно для шифрования, хранения ключей и генерации случайных чисел.
Например, у Apple есть Secure Enclave – это отдельный сопроцессор, который умеет в аппаратное шифрование, генерацию случайных чисел и имеет изолированную от всего остального мира память. Плохая новость в том, что даже в этом сопроцессоре находят уязвимости.
Ассиметричное шифрование
Ассиметричное шифрование так называется, потому что в нём используется целых два ключа: один для шифрования, а второй для расшифрования. В симметричном один ключ для всего.
Ключ для шифрования называется публичным, а ключ для дешифрования приватным. Публичный ключ можно налепить себе на лоб или набить татуировкой CYBERPUNK, но приватный нужно прятать под подушкой и никому не показывать.
С симметричным ключом у нас была большая проблема: его нужно как-то передавать и иногда менять, а единственный, видимо, надёжный способ – это личная встреча. Ассиметричное шифрование решает эту проблему, но и создаёт некоторые новые.
Вернёмся к котику, которого мы будем передавать в глобальной сети Интернет.
Мы всё так же сгенерируем AES ключ, которым зашифруем котика. Сгенерированный AES ключ мы зашифруем публичным ключом нашего друга.
Зашифрованный ключ и котика уже можно просто брать и передавать по сети. Собеседник расшифрует своим приватным ключом AES ключ, которым расшифрует собственно и самого котика. Вот такая вот многоходовочка.
А почему просто не зашифровать всё вместе публичным ключом друга? Можно и так, это тоже будет работать, но ассиметричные алгоритмы работают значительно медленнее, чем симметричные. Помните же, что мы собирались 4K HDR видео отправлять?
А какие подводные? Вам до сих пор точно нужно знать, что публичный ключ принадлежит вашему собеседнику и что приватный ключ вашего собеседника не украли. А ещё есть классическая атака, которая называется человек посередине или Man in the middle (MITM).
Электронные подписи
Электронные подписи нужны для того, чтобы точно подтвердить авторство чем-либо или согласие на что-либо. В законодательствах электронная цифровая подпись человека соответствует его собственной подписи. Вы же слышали про все эти электронные правительства?
Обычно используются схемы с ассиметричным шифрованием, но только наоборот. Публичный ключ уже используется для расшифрования, а приватный для шифрования.
Только один человек, владелец ключа, может что-то зашифровать, то есть подписать, а все остальные могут удостовериться в том, что именно владельцем ключа было зашифровано сообщение, ведь публичный ключ общеизвестный.
Обычно подписывается не всё сообщение или весь файл, а его хэш.
Сертификаты
Рядом с электронными подписями и публичными ключами часто звучит слово сертификат. Сертификат – это файл специального формата, который описывает публичный ключ.
А ещё сертификаты тоже подписывают, но другие люди или программы. Так формируются цепочки доверия. На этой технологии строится весь этот безопасный интернет и HTTPS, но про это в другой раз.
Сертификат сайта, который вы смотрите.
Сквозное шифрование
Сквозное шифрование – это не какой-то алгоритм шифрования, а подход к тому, как организован обмен данными.
Сейчас это мастхэв в мессенджерах, поэтому попытаюсь объяснить на абстрактном примере. И по большому секрету скажу, что в iMessage применяется именно такая схема.
Основной прикол в том, что у вас на устройстве генерируется публичный и приватный ключи. Публичный ключ уходит на сервер, а приватный никогда не покидает ваше устройство. Так для каждого вашего устройства.
Когда вы начинаете писать сообщение, приложение запрашивает у сервера актуальные публичные ключи вашего собеседника. При нажатии отправки происходит следующая магия:
Генерируется одноразовый AES ключ для симметричного шифрования.
Этим ключом шифруется текст сообщения, фотография, видео и всё остальное.
Комбинация из зашифрованного ключа и текста хэшируется и подписывается вашим ключом.
Всё это повторяется для каждого устройства собеседника.
Все зашифрованные сообщения отправляются на сервер, а сервер уже по возможности доставляет их на устройства вашего собеседника отсюда и статусы доставки сообщений.
Собеседник при получении сообщения сверяет подпись, расшифровывает одноразовый AES ключ, которым уже расшифровывает собственно сам текст соообщения или вложения.
С помощью такой многоходовки, никто, кроме вас и собеседника, не может прочитать сообщение. Отсюда и само название “сквозное”.
А это прямо супер-пупер безопасно? Неа. Это не делает вашу переписку абсолютно безопасной и защищённой. Вернёмся к MITM или человеку посередине.
В данном случае, этим человеком посередине может выступать ваш надёжный и защищённый мессенджер. Самое смешное, что ему для этого ничего не нужно взламывать или встраивать бэкдоры: он просто подсунет вам свой публичный ключ под видом ключа собеседника, которым вы и зашифруете сообщение.
Для того, чтобы такого не случилось, нужно сверять публичные ключи собеседника, а ещё иметь возможность увидеть какими именно ключами шифровалось конкретное сообщения, а ещё исходный код мессенджера нужно проверить на то, что он не делает чего-то плохого.
Но у мессенджера нет возможности посмотреть публичный ключ собеседника, что это значит? Что вас просят поверить на честное слово, что никто не подменяет ключ. Решайте сами.
Что ещё можно почитать?
Много всего. Если стало интересно и хочется почитать ещё про криптографию и безопасность, то вот вам оптимистичная цитата из книги “Практическая криптография” (Шнейер Брюс):
Чтобы заниматься проектированием безопасных систем, необходимо самому стать хитрым и изворотливым. Найти слабые места в собственной работе сможет только тот, кто сам начнет думать как злоумышленник. Разумеется, это повлияет и на остальные аспекты вашей жизни. Каждый, кто работал с криптографией на практике, испытал это чувство. Начав думать о том, как нападать на системы, вы будете применять это ко всему, что вас окружает. Вашу голову заполонят кошмарные мысли о том, как можно перехитрить людей и как они могут перехитрить вас. Криптографы – это профессиональные параноики. Через некоторое время вы либо научитесь отделять профессиональную паранойю от реальной жизни, либо просто сойдете с ума.
