Services on The Server

[nelkor]

I propose a new feature to manage service configurations directly from the server, with a focus on encryption and user consent. Here's an overview of the concept:

• User Consent for Server Interaction: The application should interact with the server strictly under user permission, ensuring that users retain control over their data and its exchange.
• Encrypted Configuration Storage: Service configurations should be stored on the server in an encrypted format, accessible to the user for both reading and writing operations.

Implementation Outline

The process involves generating cryptographic keys from the user's password using the PBKDF2 algorithm. Specifically:

• A private key is derived from the user's password.
• This private key is then used to generate a corresponding public key, which serves as a unique identifier (index) for storing the user's configuration on the server.
• To safeguard each configuration read/write request, we include the current timestamp and an electronic signature. This approach ensures the server can verify the freshness of the request and confirm it originates from the legitimate user, who possesses the correct password.

I welcome any suggestions, enhancements, or concerns regarding this proposal.

[nelkor]

I will continue this topic in Russian, because I'm running it alone anyway and it's more convenient for me :)

Исходная энтропия — это буфер байтов, полученный из секретного знания пользователя (исходный пароль, seed-фраза или что угодно ещё).

Исходная энтропия включает:

• зерно генерации паролей для аккаунтов;
• идентификатор;
• приватный ключ;
• публичный ключ (выводится из приватного);
• синхронный ключ;
• вектор инициализации;

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

Идентификатор Имеет небольшой размер, например 8 байтов. Применяется для генерации контента (надпись/изображение), по которому пользователь сможет убедиться в правильности исходной энтропии.

Приватный ключ Фиксированный размер 32 байта. Применяется для электронной подписи запросов. Электронная подпись приватным ключом позволяет авторизовать операцию над сущностью, обладающую публичным ключом. То есть сервер сможет быть уверен в том, что операцию выполняет тот, кто имеет на это право.

Публичный ключ Выводится из приватного, так что в исходной энтропии занимает 0 байтов. Используется в качестве ключа для сохранения конфигурации как на сервере, так и в localStorage.

Синхронный ключ Фиксированный размер 32 байта. Используется для зашифровывания и для расшифровывания конфигурации.

Вектор инициализации Фиксированный размер 24 байта. Используется вместе с синхронным ключом по алгоритму Salsa20.

ИТОГО N + 8 + 32 + 32 + 24 = N + 96 байтов, где N — размер зерна генерации паролей для аккаунтов. При N, равном 160, общее значение получается 256 байтов.

[nelkor]

Оказывается, Web Crypto API не умеет выводить асимметричные приватные ключи из произвольной энтропии. Я поисследовал существующие возможности и пришёл к выводу, что лучшим вариантом будет использование библиотеки tweetnacl. Она мало весит и её код мне нравится.

Помимо асимметричного ключа, который нужен для электронной подписи (tweetnacl использует алгоритм электронной подписи Ed25519) в библиотеке есть ещё пару крутых реализаций, которых нет в Web Crypto API и которые можно взять на вооружение в Passcryptum. Во-первых, это хеш-функция BLAKE2b, и во-вторых, алгоритм симметричного шифрования Salsa20.

[nelkor]

Примеры запросов сервера

Сохранение конфигурации POST-запрос. Публичный ключ в заголовке. Тело запроса:

• Первые 64 байта — сигнатура по Ed25519;
• Следующие 4 байта — timestamp (беззнаковое до 4294967295);
• Далее и до конца — зашифрованная конфигурация;

Подписываются и timestamp и конфигурация вместе. Таким образом, сервер может как авторизовать запрос, так и провалидировать его свежесть.

Получение конфигурации GET-запрос. В заголовках:

• Публичный ключ;
• Timestamp;
• Сигнатура timestamp.

Почему не отдаём любой конфиг кому угодно (он ведь зашифрованный) — чтобы нельзя было следить за изменениями.

[nelkor]

Примеры кода

Хеширование

import { hash } from 'tweetnacl'
import { decodeUTF8 } from 'tweetnacl-util'

const seed = '123'
const seedHash = hash(decodeUTF8(seed)) // Uint8Array 64 bytes

Электронная подпись

import { sign } from 'tweetnacl'

// Обе эти сущности — Uint8Array
import { keyPairSeed } from './entropy' // 32 bytes
import { bufferData } from './text-data'

const { secretKey, publicKey } = sign.keyPair.fromSeed(keyPairSeed)

const createSignarute = (data: Uint8Array) =>
  sign.detached(data, secretKey)

const verifySignature = (data: Uint8Array, signature: Uint8Array) =>
  sign.detached.verify(data, signature, publicKey)

const signarute = createSignarute(bufferData)
const isValid = verifySignature(bufferData, signarute)

console.log(signarute)
console.log(isValid ? 'VERIFIED' : 'NOT verified')

Шифрование

import { secretbox } from 'tweetnacl'

import { secretBoxIv, secretBoxKey } from './entropy' // Uint8Array 24 and 32 bytes
import { bufferData } from './text-data' // Uint8Array

export const encrypt = (data: Uint8Array) =>
  secretbox(data, secretBoxIv, secretBoxKey)

export const decrypt = (data: Uint8Array) =>
  secretbox.open(data, secretBoxIv, secretBoxKey)

const encrypted = encrypt(bufferData)
const decrypted = decrypt(encrypted)

console.log('source', bufferData)
console.log('encrypted', encrypted)
console.log('decrypted', decrypted)

[nelkor]

Онлайн PIN

Мотивация: хранить исходную энтропию на сервере (под защитой PIN). Так сложнее перебирать PIN, чем если бы он хранился на устройстве (как в Passcryptum 2). Исходная энтропия на сервере должна храниться в зашифрованном виде. Ключ расшифровки в это время хранится на устройстве (например, localStorage). Таким образом, для каждого нового устройства необходимо новое хранилище.

Во избежание перебора PIN зашифрованная исходная энтропия сохраняется под уникальным ключом, который также хранится на устройстве (далее — "протектор"). Чтобы воспользоваться своим онлайн PIN, необходимо:

• иметь на устройстве протектор;
• знать PIN;
• иметь на устройстве ключ расшифровки.

Если забыл PIN — ничего страшного, просто выводишь свою исходную энтропию из источника (например, исходный пароль) и устанавливаешь новый онлайн PIN.

Установка PIN

Для сохранения передаём серверу:

• Публичный ключ;
• Зашифрованную исходную энтропию;
• Значение PIN;
• Временную метку;
• Сигнатуру;

В ответ сервер отправляет протектор.

Запрос энтропии с PIN