TL; DR
SealTask шифрує читабельний вміст робочого простору на вашому пристрої за допомогою ChaCha20-Poly1305 до синхронізації. Сервіс не зберігає ключів для розшифрування цього вмісту, але продовжує обробляти метадані облікового запису, білінгу, безпеки, аудиту, сервісу й робочого простору. Збережений вами резервний ключ може один раз відновити доступ після втрати пароля. Така архітектура сприяє мінімізації даних; регульоване використання однаково потребує належних угод і засобів контролю.
Термін безпеки має описувати межу, а не прикрашати твердження.
Терміни зі сторінок SealTask про безпеку, посібники, порівняння та інциденти. Поняття з повним поясненням ведуть на канонічну сторінку.
Відкрити весь центр знаньНаш основний принцип.
Читабельний вміст робочого простору шифрується на вашому пристрої до надсилання на наші сервери. SealTask спроєктовано так, щоб компанія не могла розшифрувати відкритий текст завдань, нотаток, коментарів, чеклістів, назв списків і вкладень. Сервіс продовжує обробляти перелічені нижче метадані. Цю межу захисту вмісту ми називаємо нульові знанняархітектура.
Що робить SealTask різні.
Традиційні менеджери завдань.
Що роблять конкуренти
- • Зберігайте свої дані у вигляді відкритого тексту на своїх серверах
- • Може читати кожне створене вами завдання, коментар і файл
- • Може сканувати ваш вміст на наявність реклами, навчання AI або «функцій»
- • Злам або авторизований шлях доступу може розкрити читабельний вміст і метадані
SealTask (нульовий рівень знань).
Що ми робимо
- • Шифрує на вашому пристрої перед надсиланням на наші сервери
- • Ми не можемо розшифрувати ваші завдання, навіть якби хотіли
- • Ні сканування, ні навчання AI на вашій приватній роботі
- • Злам бази може розкрити шифротекст і метадані, але не читабельний вміст без клієнтських ключів
Як шифрування з нульовим знанням працює.
Ви створюєте свій обліковий запис.
Коли ви реєструєтеся, ваш пароль ніколи не залишає ваш браузер у відкритому вигляді. Замість цього:
- Ми використовуємо протокол OPAQUE PAKE, щоб наші сервери ніколи не бачили ваш пароль у відкритому вигляді
- Після успішної реєстрації або входу OPAQUE надає вашому браузеру секретний експортний ключ, який ми ніколи не отримуємо
- На вашому пристрої генерується випадковий 32-байтовий «ключ даних».
- Цей ключ даних локально шифрується ключем обгортки, отриманим з експортного ключа OPAQUE
- Зашифрований ключ даних зберігається на наших серверах — алеми не можемо його розшифруватибез клієнтського матеріалу для розблокування
- Ви можете завантажити одноразовий резервний ключ. Він обгортає той самий ключ даних у вашому браузері, а ми зберігаємо лише зашифровану обгортку відновлення
Ключовий момент: ключ розблокування та ключ даних обробляються у вашому браузері. Ми зберігаємо лише зашифровані обгортки, а не відкриті паролі чи ключі робочої області.
Навіщо зберігати зашифрований ключ даних?
Тож ви можете увійти з будь-якого пристрою. Коли ви змінюєте комп’ютер або користуєтеся телефоном, ми надсилаємо вам зашифрований блок, ви повторно вводите свій пароль, щоб розшифрувати його локально, і повертаєтеся. Не зберігаючи його, вам потрібно буде вручну скопіювати 32-байтний ключ між пристроями — жахливий UX для тієї самої безпеки.
Ви створюєте SealTask або завдання.
Читабельний вміст шифрується на вашому пристрої; операційні метадані залишаються видимими серверу:
- Назви й описи робочих списків
- Назви завдань, тексти, контрольні списки та коментарі
- Вміст шаблону повторюваного завдання зашифровано; cron-розклад, часовий пояс, активний стан, номер ітерації та час матеріалізації залишаються видимими серверу
- Все зашифровано за допомогоюChaCha20-Poly1305 AEAD(сучасний перевірений шифр)
- Кожен SealTask має власний унікальний ключ шифрування, отриманий з вашого ключа даних
Сервер зберігає зашифровані дані робочого простору й оголошені операційні метадані; без клієнтських ключів він не може прочитати зашифрований відкритий текст.
Ви запрошуєте членів команди.
Коли ви ділитеся списками роботи з колегами:
- Кожен учасник отримує власну зашифровану копію ключа SealTask
- Обмін ключів здійснюється за допомогоюHPKE(Гібридне шифрування відкритим ключем)
- Відкриті ключі запрошень записуються до журналу прозорості Merkle. Клієнт, який зберігає раніше довірену контрольну точку, може виявити невідповідність під час перевірки, але поточний клієнт не залишається закритим після помилки й не зберігає це виявлення: він може відкинути точку та повторити перевірку від початку
- Видалення учасника відкликає його авторизований сервером доступ до списку. Сервер, який фіксує зміну, після коміту сповіщає свої активні потоки; зміни з іншого сервера, масові або не позначені сигналом перевіряються повторно щонайпізніше за 30 секунд. Уже доставлені або буферизовані транспортом дані відкликати не можна. Поточна версія не обертає ключ списку автоматично, не перешифровує список і не стирає вміст чи ключі, отримані під час дозволеного доступу. Для нової криптографічної межі створіть новий список лише для поточних учасників.
Сервер перевіряє узгодженість HMAC без розшифрування даних.
Доступ авторизують стан сесії та активного членства в базі даних. Окремо браузер виводить із ключа списку за допомогою HKDF і фіксованої протокольної константи ключ прив’язки даних для цього списку; той самий ключ копіюється для кожного членства та зберігається сервером.
Сервер використовує цей ключ для перевірки HMAC над шифротекстом. Доказ лише показує відповідність HMAC байтам шифротексту без їх розшифрування.
- Браузер виводить ключ прив’язки для списку з ключа списку за допомогою HKDF; це не ключ розшифрування вмісту робочого простору
- Перед авторизацією запиту сервер перевіряє автентифіковану сесію й активне членство
- Сервер зберігає скопійований ключ прив’язки та може перевіряти або обчислювати відповідні HMAC над шифротекстом
- HMAC не доводить свіжість, не запобігає повторному надсиланню, не прив’язує дані до сутності чи учасника й не підтверджує автентичність перед сервером
Що можуть наші сервери (і не може) бачити.
Ми НЕ бачимо
- × Читабельні назви завдань
- × Читабельні тексти завдань і нотаток
- × Читабельний вміст шаблонів повторюваних завдань
- × Читабельні тексти коментарів
- × Читабельний вміст чеклістів
- × Читабельні назви й описи списків
- × Відкритий текст вкладень
- × Паролі облікових записів у відкритому вигляді
- × Ключі розшифрування вмісту робочого простору
Невичерпні приклади видимих метаданих робочого простору
- ✓ Електронна адреса облікового запису користувача (для входу)
- ✓ Членські відносини (хто в якому SealTask)
- ✓ Статус завдання (відкрито/закрито) і пріоритет
- ✓ Терміни виконання та позначки часу
- ✓ Призначення делегування (лише ідентифікатори користувачів)
- ✓ Метадані, необхідні для запитів (ідентифікатори, дати створення)
- ✓ Солі й докази для кожного членства, а також збережений сервером ключ прив’язки даних для списку, яким сервер перевіряє або обчислює відповідні HMAC; це не ключ розшифрування вмісту робочого простору
- ✓ Розклад повторень, часовий пояс, активний стан, ітерація та час матеріалізації
- ✓ Зв’язки вкладень, ідентифікатори сховища, розмір шифротексту, стан і часові позначки
- ✓ Типи подій реального часу, ідентифікатори учасників і сутностей, назви змінених полів, часові позначки та кількість пропущених подій
Обсяг і чутливість: Показаний перелік містить невичерпні приклади видимих серверу метаданих робочого простору; це не повний перелік поточних моделей зберігання, відповідей API чи подій SSE. Це також не повний реєстр персональних даних: автентифікація облікового запису, білінг, безпека й аудит, запобігання зловживанням і телеметрія сервісу є окремими сферами, невичерпно описаними в політиці приватності. Метадані самі можуть бути чутливими. Розмір шифротексту вкладення зазвичай приблизно розкриває розмір початкового файлу.
Безпека гарантії.
Розблокування на основі пароля (тільки для клієнта).
Ваш пароль ніколи не залишає пристрій у відкритому вигляді. Успішна автентифікація OPAQUE надає браузеру експортний ключ, який локально розгортає ключ даних. Потім HKDF розширює ключ даних для отримання окремих ключів кожного робочого списку.
Сервер не може розшифрувати корисні дані.
Backend не розшифровує зашифровані дані робочого простору. Запити авторизують перевірки сесії та членства в базі. Збережений ключ прив’язки для списку дає серверу змогу перевірити або обчислити HMAC, що відповідає шифротексту; це доводить узгодженість шифротексту, але не свіжість, захист від повторного надсилання, прив’язку до сутності чи учасника або автентичність перед сервером.
Відкликання доступу обмежене й не має зворотної дії.
Видалення учасника відкликає його авторизований сервером доступ до списку. Сервер, який фіксує зміну, після коміту сповіщає свої активні потоки; зміни з іншого сервера, масові або не позначені сигналом перевіряються повторно щонайпізніше за 30 секунд. Уже доставлені або буферизовані транспортом дані відкликати не можна. Поточна версія не обертає ключ списку автоматично, не перешифровує список і не стирає вміст чи ключі, отримані під час дозволеного доступу. Для нової криптографічної межі створіть новий список лише для поточних учасників.
Прозорість ключів.
Відкриті ключі запрошень записуються до Merkle-дерева лише з додаванням записів. Раніше довірена контрольна точка може виявити невідповідність під час перевірки, але поточний клієнт може відкинути її та повторити перевірку від початку; ця спроба й перше використання залишаються межами довіри, а не безумовним захистом.
Резервні ключі залишаються з нульовим знанням.
Резервний ключ створюється у вашому браузері, і його маєте зберегти ви. Він створює окрему зашифровану обгортку для того самого ключа даних; ми зберігаємо лише файл облікових даних відновлення та зашифровану обгортку, тому не можемо скинути ваш пароль або прочитати дані без цього збереженого ключа.
Криптографія з відкритим кодом.
Ми використовуємо перевірені в боях бібліотеки: сейф (ChaCha20-Poly1305), Argon2id (виведення ключів), OPAQUE (автентифікація пароля) і HPKE (обмін ключами). Весь наш криптографічний код є відкритим і підлягає перевірці.
Як ми перевіряємо наша безпека.
Наші заяви про безпеку можна перевірити, а не лише прочитати в маркетингових матеріалах. Ось як ми перевіряємо задокументовані властивості архітектури:
- Криптографічний код із відкритим кодом, доступний на GitHub для публічного аудиту дослідниками безпеки
- Перевірені в боях бібліотеки, включаючи ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9807) і HPKE
- Збережений сервером ключ прив’язки для списку дає змогу перевірити або обчислити HMAC, що відповідає шифротексту; доступ авторизують перевірки сесії та членства в базі, а HMAC не доводить свіжість, захист від повторного надсилання, прив’язку до сутності чи учасника або автентичність перед сервером
- Докази Merkle можуть показати невідповідність відносно довіреної контрольної точки, але поточний клієнт може відкинути її та повторити перевірку від початку
- Клієнтське розблокування через експортний ключ OPAQUE не передає сервісу пароль у відкритому вигляді чи ключі розшифрування вмісту
- Одноразові резервні ключі створює та зберігає користувач, а не SealTask
Компроміси нульові знання.
Резервний ключ може відновити доступ після втрати пароля.
Збережіть одноразовий резервний ключ і тримайте його приватним. Після втрати пароля цей ключ дає змогу скинути його й зберегти доступ до зашифрованих даних. Оскільки SealTask не зберігає копії, обліковий запис без збереженого резервного ключа відновити неможливо.
Без пошуку на стороні сервера.
Оскільки вміст вашого завдання зашифровано, ми не можемо забезпечити повнотекстовий пошук на стороні сервера для всіх ваших завдань. Пошук відбувається у вашому браузері після розшифровки.
Пом’якшення: ми оптимізуємо пошук на стороні клієнта за допомогою індексованого пошуку та швидкого розшифрування, щоб підтримувати його ефективність.
технічний технічні характеристики.
| Симетричне шифрування | ChaCha20-Poly1305 AEAD (via strong-box library) |
| Розблокування ключа даних | Експортний ключ OPAQUE + HKDF-SHA256 — отримує локальні ключі обгортки для зашифрованого ключа даних |
| Ключова ієрархія | HKDF-SHA256 — виводить ключі проєктів і членства з ключа даних |
| Автентифікація пароля | OPAQUE PAKE (Ristretto255 curve) |
| Двофакторна автентифікація | TOTP із застосунку-автентифікатора (RFC 6238) з одноразовими резервними кодами; вмикається за бажанням для облікового запису |
| Резервні ключі | Один активний одноразовий резервний ключ на користувача; створюється на стороні клієнта і зберігається користувачем |
| Обмін ключами (запрошення) | HPKE (Hybrid Public Key Encryption) with X25519 |
| Перевірки узгодженості даних | HMAC-SHA256 |
| Серіалізація | CBOR (Concise Binary Object Representation) |
| Розмір ключа | 256-bit (32 bytes) for all symmetric keys |
Усі криптографічні операції виконуються у вашому браузері за допомогою API WebCrypto та перевірених модулів WASM, скомпільованих із Rust.
аудити та прозорість.
Криптостек з відкритим кодом.
Уся наша криптографічна реалізація є відкритою та доступна на GitHub. Ми запрошуємо дослідників безпеки до перевірки нашого коду.
Переглянути на GitHubВідповідність.
Наша архітектура з нульовими знаннями підтримує мінімізацію даних GDPR і може допомогти з технічними гарантіями. До будь-якого використання PHI SealTask має надати пряму письмову згоду. Якщо застосовується HIPAA, сторони до початку використання повинні укласти BAA, що відповідає HIPAA. Шифрування — лише один захід; програма відповідності має забезпечити потрібні операційні засоби контролю й оцінку постачальника.
Поширений запитання.
Що станеться, якщо вас зламали?
Зловмисник із доступом до бази може отримати шифротекст, а також метадані облікового запису, маршрутизації, аудиту й робочого простору. Збережений вміст не читається без клієнтських ключів розшифрування; захист також залежить від криптографії, клієнтів і поводження з ключами.
Чи можуть державні установи змусити вас розшифрувати мої дані?
Законна вимога може зобов’язати нас надати шифротекст і видимі серверу метадані облікового запису, білінгу, безпеки, аудиту, сервісу й робочого простору. Ми не зберігаємо ключів, потрібних для розшифрування читабельного вмісту.
Що буде, якщо я забуду пароль?
Якщо ви зберегли резервний ключ, ви можете використати його один раз, щоб скинути пароль і зберегти доступ до зашифрованих даних. Якщо ви не зберегли резервний ключ, SealTask не зможе відновити дані для вас.
Чим це відрізняється від «зашифрованого в стані спокою»?
«Зашифровано в стані спокою» означає, що дані зашифровано на жорстких дисках сервера, але сервер усе ще має ключі для їх розшифровки. Наскрізне шифрування означає, що лише ви (кінцеві точки) маєте ключі — сервер ніколи не має доступу у відкритому вигляді.
Чи можуть співробітники SealTask бачити мої дані?
Працівники SealTask і адміністратори бази не мають клієнтських ключів для розшифрування даних робочого простору. Авторизовані системи й працівники все одно можуть мати доступ до видимих серверу метаданих, описаних на цій сторінці.
Що робити, якщо я хочу експортувати свої дані?
Ви можете будь-коли експортувати розшифровані дані з програми. Оскільки розшифровка відбувається у вашому браузері, ви отримаєте читабельні файли JSON/CSV, а не зашифровані блоки.
Чи підтримує SealTask двофакторну автентифікацію?
Так. У налаштуваннях безпеки можна ввімкнути двофакторну автентифікацію через застосунок-автентифікатор (RFC 6238 TOTP) і зберегти одноразові резервні коди. Для входу тоді потрібні пароль і актуальний код. Це захищає вхід до облікового запису й діє окремо від клієнтського шифрування, яке захищає вміст робочого простору.
Посилання та стандарти.
Наш криптографічний вибір відповідає галузевим стандартам і рецензованим специфікаціям.
- 01 RFC 8439: ChaCha20 і Poly1305 для протоколів IETF — Наш стандарт симетричного шифрування
- 02 RFC 9807: розширений протокол OPAQUE PAKE — Автентифікація з нульовим знанням пароля
- 03 RFC 9180: Гібридне шифрування з відкритим ключем (HPKE) — Обмін ключів на командні запрошення
- 04 RFC 9106: Argon2 Memory-Hard Function — Виведення ключа на основі пароля
- 05 NIST SP 800-175B: Рекомендації щодо використання криптографічних стандартів — Федеральне криптографічне керівництво
- 06 Стаття 32 GDPR: Безпека обробки — Вимоги ЄС щодо захисту даних
- 07 RFC 6238 — TOTP — Двофакторна автентифікація
Готовий до реальна конфіденційність?
Приєднуйтесь до команд, які довіряють SealTask, щоб зберегти свою роботу справді конфіденційною. Почніть з Free — кредитна картка не потрібна.
Почати безкоштовноВиникли питання безпеки? Пишіть нам на адресу security@sealtask.com