Шифруется на вашем устройстве.Проверяется на вашем устройстве.

01

Вход в аккаунт и расшифровка — отдельные действия

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

02

Как создаются и разблокируются ваши ключи

При настройке аккаунта на устройстве создаются случайный 256-битный корневой ключ и пара ключей подписи ECDSA P-256. Корневой ключ и закрытый ключ подписи хранятся в зашифрованном пакете ключей аккаунта. Сервер получает зашифрованные копии этого пакета и открытый ключ проверки подписи.

Парольная фраза шифрования нормализуется по Unicode NFKC и обрабатывается Argon2id со случайной солью длиной 16 байт, 64 MiB памяти, 3 итерациями и параллелизмом 4. Полученный 256-битный ключ защищает пакет ключей аккаунта с помощью AES-GCM. Эти параметры замедляют перебор паролей, но надёжная уникальная парольная фраза по-прежнему необходима.

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

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

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

03

Шифрование файлов и роль Google Tink

Каждая новая редакция файла получает новый случайный 256-битный ключ содержимого. Файлы шифруются сегментами с проверкой подлинности, поэтому клиенты могут загружать большие файлы и читать нужный диапазон без предварительной расшифровки всего файла. Открытые данные каждого сегмента становятся доступны только после его проверки.

InfiniDrive реализует формат передачи данных, совместимый с профилем потокового AEAD RAW AES256_GCM_HKDF_1MB библиотеки Google Tink. HKDF-SHA-256 вырабатывает AES-ключ для каждого потока из ключа содержимого и новой соли. Nonce каждого сегмента объединяет случайный префикс, индекс сегмента и признак последнего сегмента. Формат обеспечивает проверку подлинности позиции сегмента и завершённости потока.

Совместимость с Google Tink проверяется тестами шифрования и расшифрования в обоих направлениях.

04

Метаданные, подписи и проверка версий

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

Подписи ECDSA P-256 с SHA-256 защищают манифесты и операции с аккаунтом. Прежде чем открыть доступ к содержимому, клиенты проверяют подписи, идентификаторы объектов и контекст редакции. При проверке истории ответы сервера сравниваются с контрольными точками, сохранёнными локально, чтобы обнаружить откат или противоречащую историю относительно того, что это устройство уже наблюдало.

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

05

Фото, превью и ссылки общего доступа

Поддерживаемые клиенты создают превью изображений и видео локально. У превью есть собственный случайный ключ редакции, и оно шифруется до загрузки. Его зашифрованные и подписанные метаданные связывают его с редакцией исходного файла. Служба доставки превью хранит и передаёт зашифрованные байты; клиент проверяет и расшифровывает изображение.

Зашифрованная публичная ссылка содержит секрет для расшифровки во фрагменте URL после символа #. Браузеры не включают этот фрагмент в HTTP-запрос к серверу. Браузер получателя использует секрет локально, чтобы разблокировать содержимое по ссылке.

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

Любой, у кого есть полная ссылка, может использовать её секрет, поэтому обращайтесь со ссылкой как с доступом к файлу. Отзыв ссылки может остановить дальнейший доступ через сервис, но не может стереть копию, которую получатель уже скачал или расшифровал.

06

Где хранятся ключи и файлы в открытом виде

Нативные клиенты могут сохранять разблокированные ключи аккаунта с защитой операционной системы: Keychain на платформах Apple, защищённое хранилище на базе Android Keystore и DPAPI для отдельного пользователя в Windows. Во время расшифровки приложению нужны доступные для использования ключи; хранилище операционной системы не делает скомпрометированное разблокированное устройство безопасным.

Блокировка диска и выход из аккаунта ограничивают дальнейшее использование его ключей. Файлы в открытом виде, уже скачанные через Finder, Проводник, экспорт или другое приложение, могут остаться на диске. Для локальных файлов, кешей миниатюр операционной системы, резервных копий и других приложений действуют собственные правила защиты и хранения.