DOU Проектор: encrypt.one — сервис безопасной передачи данных

В рубрике DOU Проектор все желающие могут презентовать свой продукт (как стартап, так и ламповый pet-проект). Если вам есть о чем рассказать — приглашаем поучаствовать. Если нет — возможно, серия вдохновит на создание собственного made in Ukraine продукта. Вопросы и заявки на участие присылайте на editors@dou.ua.

Здравствуйте! Меня зовут Максим Хомутин, и последние 4 года я работаю IT-стартапером. Раньше я работал акционером и директором портала I.UA. Вместе со мной тянут соху мои коллеги и братья по оружию — Денис Мисько, Виталий Хранивский и Ярослав Слободянюк. Все — ключевые члены команды создателей I.UA, да что там I.UA — мы даже Bigmir.net еще вместе делали. Наша компания называется Final Level, что символизирует сложность и эпичность решаемых задач. :)

Хотим представить уважаемой аудитории DOU нашу последнюю разработку — сервис безопасной передачи данных encrypt.one.

Идея

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

Передача паролей через мессенджеры, флешки или сервисы хранения файлов — Google Drive или Dropbox — небезопасна. Мессенджер или аккаунт одного из звеньев передачи информации могут взломать и приватные данные попадут к злоумышленникам. Кроме того, существующие сервисы передачи паролей вроде OneTimeSecret из-за отсутствия шифрования на стороне пользователя подвержены рискам взлома и не предоставляют возможности передавать файлы.

Ну а так как в наше время спокойно себя чувствовать не может даже президент США (русские хакеры не дремлют), мы решили озаботиться решением проблемы абсолютно невзламываемого сервиса передачи секретных данных. Так появился encrypt.one.

Основная задача сервиса — пересылка любой секретной текстовой информации (паролей от сервисов, данных кредитных карт) а также небольших файлов до 5 Мб, при этом бонусом encrypt.one предлагает уверенность, что пересылаемые данные не попадут к третьей стороне.

Реализация

Реализация проекта заняла около четырех недель, из них полторы недели ушло на backend development, остальное время потратили на разработку сайта, А/В тесты интерфейса и т.д.

Backend написан на Go, для шифрования на стороне браузера использовалась библиотека github.com/brix/crypto-js, для генерации паролей и ключей используется crypto API браузера. Хранение написано как интерфейс, соответственно можно использовать какие угодно системы хранения. На данный момент реализовано хранение в памяти и на диске.

Для сохранения файлов на стороне пользователя использовались blob URL по средствам URL.createObjectURL(), что позволило расшифровывать данные на стороне пользователя и сохранять файлы большого размера.

Само шифрование организовано по стандарту AES-256 (Advanced Encryption Standard), который Агентство Национальной Безопасности США относит к уровню «Совершенно Секретно». Для взлома AES-256 методом подбора современному компьютеру понадобится несколько миллиардов лет, этот стандарт используется в банковских системах и не был взломан ни разу за всю историю криптографии.

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

Исходный код encrypt.one доступен на Github.

Сейчас над проектом работают: Денис Мисько — основной идеолог и разработчик проекта, Ярослав Слободянюк — дизайн, верстка, Виталий Хранивский — фронтенд разработка, ну и я занимаюсь скучными вопросами маркетинга и общего менеджмента.

Максим Хомутин, CEO Final Level Денис Мисько, CTO Final Level

Результаты

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

Поскольку проект стартовал совсем недавно, похвастаться миллионными аудиториями мы, к сожалению, пока не можем. В среднем, в сутки сервисом сейчас пользуется порядка 1000 человек. Увеличивать эту цифру с помощью маркетинга или PR планируем позже. Наш основной план на сегодня — получить обратную связь от пользователей и понять, в каком направлении стоит развивать encrypt.one в дальнейшем, ведь останавливаться на текущем функционале мы не хотим.

Что касается монетизации, видим один из путей развития в корпоративном сегменте, хотим довести продукт до «коробки», чтобы компании могли поднимать его на своем оборудовании и решать вопрос внутреннего обмена конфиденциальной информацией.

Будем очень благодарны отзывам и комментариям читателей, спасибо за внимание!

LinkedIn

36 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

там тоже функционал минимален

Основная задача сервиса — пересылка любой секретной текстовой информации (паролей от сервисов, данных кредитных карт) а также небольших файлов до 5 Мб, при этом бонусом encrypt.one предлагает уверенность, что пересылаемые данные не попадут к третьей стороне.
В итоге у нас получился компактный и лаконичный сервис, основная особенность которого состоит в том, что все данные шифруются ключом на стороне браузера и только после этого передаются на сервер. Как результат, на сервер передается зашифрованная информация, которую не смогут расшифровать ни сотрудники сервиса, ни русские хакеры, которые теоретически могут получить доступ к базе данных, так как у них нет ключа для расшифровки.
не смогут расшифровать ни сотрудники сервиса

Что мешает сотрудникам сервиса на день другой поменять код фронтенда и собирать

данных кредитных карт

?

Около 2-x лет назад мы тоже разработали подобный сервис (безопасная передача текстовых данных), по большей части для внутренних нужд и для друзей, а также в качестве эксперимента и развлечения, в попытке совместить лучшие практики шифрованных pastebin’ов. Он назвается RavelCast. Если кому-то интересно, там же можно ознакомиться с описанием сервиса.

«Никакие права не сохранены. Использование материалов сайта без согласия авторов настоятельно поощряется. »
Смешно))

В продолжение темы об аналогичных и давно существующих сервисах: secserv.me с групповым онлайн-чатом и другие по ссылке rulus.ru/...ия_для_анонимного_общения

I.UA — представительство Ольгино в Украине (судя по контингенту). Это бросает тень на ваш продукт.

основная особенность которого состоит в том, что все данные шифруются ключом на стороне браузера и только после этого передаются на сервер. Как результат, на сервер передается зашифрованная информация, которую не смогут расшифровать ни сотрудники сервиса, ни русские хакеры, которые теоретически могут получить доступ к базе данных, так как у них нет ключа для расшифровки.
скажите, чем это отличается от Signal, WhatsApp, Facebook Messenger, Telegram и еще двух десятков мессенджеров?

Ну сервис имеет право на жизнь, но без расширения функционала мало интересен.. Передача текста это конечно хорошо, но обычно возникает необходимость в передаче файлов, а сейчас для этого придется использовать сторонний сервис.. Вот что было бы интересно:

1) короткие ссылки
2) peer-to-peer передача данных, подтверждение начала передачи отправляющей стороной

Передача файлов как раз в нем реализована. Пока до 5 мб, но можно и расширить в перспективе

Не поздно ли? Идея trusted sharing активно реализовывалась еще в 12 году. Да и тех, кто это умеет и из браузера и из своих мобильных приложений, в том числе добавляя watermark, устанавливать время просмотра и т.д. полно, например — www.encryptedcloud.com

В общем интересно было бы понять ваши планы, во что расти собираетесь? И что у вас паролем происходит? стандартный sha256 c 4гб ключем?

Кажется, вы переизобрели Mega (mega.nz), основанный небезызвестным Кимом Доткомом.

да проект Mega был вдохновителем нашего проекта (в смысле того что он использует шифрование на стороне браузера), разница только в том что Mega это сервис хранения, encrypt.one передачи информации.

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

да все взламывается, вопрос сколько на это нужно времени :)

Госструктуры Украины, да и владельцы ключей украинских АЦСК (ДФС, Казначейства, Минюста, ...) между собой будут таким пользоваться, обменявшись открытыми сертификатами. www.iit.com.ua/downloads
Те же предприниматели и физ.лица обменявшись (просто стянув сертификаты друг друга сайта АЦСК ДФС) и затянув их в ПО «Користувач ЦСК» могут гарантированно без оплаты кому-либо обмениваться закрытой информацией друг с другом, посылая ее как им удобно и привычно.

Для шифрования используется либо введенный пароль, либо случайно сгенерированный ключ который помещается в хеш-часть ссылки и не передается на сервер. Браузер получателя ссылки расшифровывает информацию непосредственно на компьютере пользователя при помощи введенного пароля или ключей из хеш-части ссылки.
Вопрос: а пароли и ссылки к зашифрованному паролю/файлу каким сервисом передавать? Чем и кем гарантируется тот факт, что конечным получателем реквизитов раскрытия посылки и первого/единственного её раскрытия будет истинное лицо получателя. Ведь прискорбно будет узнать, что посылка уже вскрылась, и информация ушла на сторону, так как у кого-то стояли заранее внедренные грабберы,так как обмен обоих сторон уже давно был интересен третьей стороне.

Или перехватили передаваемую ссылку с хеш-паролем, посмотрели, создали новую и скормили конечному получателю.

1) информация от сервера передается пользователю и сразу удаляется, те если получатель при получении ссылки получил сообщение что ссылка была не найдена, то это означает что информация была скомпроментирована.
2) при использовании ссылки с паролем, пароль может быть передан другими средствами связи — например: сама ссылка в месенджере, а пароль по телефону голосом :) (в любом случае учитывая очень короткий срок жизни информации (до первого открытия), окно аттаки очень ссужается, чем в случае если информация была передана на носителе который не контролирует удаление по получению )

1) при подмене ссылки, о том что она скомпрометирована он будет очень долго об этом не знать.
2) почему бы не задействовать смс и телефоны, чтоб хоть как-то заранее уточнить и зафиксировать лиц обеих сторон.
Например, я ввожу номер телефона отправителя, на которого хочу зашифровать посылку и он преобразовавшись встраивается в хеш-сылку и он же участвует в шифрации. Раскрывающий перейдя по ссылке и запрашивая раскрытие посылки, добавляет еще и ключевую пару — номер своего телефона (если у него их несколько, я ему сообщу на какой из и в тел.разговоре) и поступивший на него код (сразу после ввода телефона для раскрытия). Тогда получающий будет узнавать не о том, что инфу увели уже — большой привет — открыть можно только один раз и уже открывалось. А о том, что ее пытаются увести, так как на телефон залетит смс-ка с кодом подтверждения для раскрытия, которого он еще и не собирался делать.

просто если информация важная и нужен максимальный уровень паранойи то:
1) пароль можно оговорить вначале, например при личной встрече
2) потом перед отсылкой ссылки дождаться что человек готов ее сразу принять
3) отослать ссылку и потвердить получение, если получение не подтверждено в течении 1-2 минут — нажать на удалить ссылку

Как на меня это сервис, и мне бы его хотелось получить, а не организовывать самому.
1 смс получателю — вам посылка, сайт, код посылки, просьба забрать в теч. 10 минут.
Вошел, ввел код — получил доступ к посылке.
На вопрос о телефоне получателя, ввел его.
2 смс получателю — ваш код доступа
На вопрос подтвердить себя — ввел код из смс.
Если я еще после того, как все ввел на сервисе должен как-то самостоятельно утрясать с получателем передачу снова, но уже другого по сути, пароля/ссылки, чего я тогда первое таким же образом не могу утрясти, передать.
Ситуация с обменом открытыми ключами не в том, что это проще/сложнее, а в том, что я заранее знаю конкретное лицо, которое отмутузю за утечку информации, из-за компрометации им своего закрытого ключа. А с применением подобного сервиса мне кому морду бить и за что, чтоб хоть моральную компенсацию получить, если вякнет, что посылку уже раскрыли до того как?

На текущий момент баззворд по этой теме keybase.io ;

Но они еще не набрали критической массы пользователей.

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

в случае компрометации приватного ключа — у всех проблемы :)
У кейбейс, кста, уже решена проблема обмена приватными файлами напрямую. Весьма удобно.

Окно хранения ? Я, как получатель, предпочитаю сам решать, что делать с полученной информацией — и уж точно без какого либо контроля со стороны отправителя.

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

Вы не смогли найти PGP/GnuPG?

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

Вы вообще понимаете разницу между симметричной и асимметричной криптографией? При обмене открытыми ключами единственное, о чём надо беспокоиться — так это о подмене ключей по пути. У вас в сервисе предусматривается передача паролей, которая принципиально уязвима к пассивному перехвату; следовательно, передачу паролей от передаваемого файла надо производить по заведомо надёжному каналу. Рекурсия.

Вообще всё это ужасно, просто чудовищно. Криптоаналитики годами исследуют алгоритмы, каждую строчку криптографических библиотек внимательно рассматривали тысячи людей, правительство США годами судилось с Филом Циммерманом, энтузиасты в OpenPGP и GnuPG десятилетиями ищут (и иногда находят) уязвимости, живыми людьми придумано много практик вроде key signing party... и тут в 2017 году приходят такие вот оптимистично настроенные люди с сервисом, который «гарантирует, что информация будет прочитана только один раз» и заявляют, что у них уровень безопасности «такой же», как у PGP. Плюс-минус.

Ламерьё позорное.

1) да я в курсе чем отличается симметричная и асимметричная криптография
2) OpenPGP внутри использует AES для шифрования самих данных, асиметричные ключи используются только для зашифровки генерируемого AES ключа.
3) PGP это не алгоритм шифрования к вашему сведению, а формат/набор утилит.
4) криптостойкость симметрических и ассиметрических алгоритмов зависит от длины ключа и и самих алгоритмов, и при прочих равных они имеют одинаковую криптостокость. (учите матчасть)
5) также учтите что в случае компрометации приватного ключа, вся посланная информация зашифрованная при помощи соответствующего публичного ключа будет расшифрована. В случае же одноразовых сервисов передачи информации, на каждую передачу генерируется новый ключ и ключ генерируется на стороне пользователя, те может быть передан другими средствами связи отдельно от ссылки, и в любом случае будет валиден только для данной передачи и только раз + сама информация удаляется сразу после получения, те даже перехват ссылки в будущем (например из истории переписки и тп, ничего не даст взломщику).

Плюс в тому що будеш знати, що інформацію хтось прочитав, мінус в тому, що не знаєш як комусь безпечно передати ссилку і пароль. Проблему перехвату інформації ваша система не вирішує!!!!

Главная задача подобных систем максимально уменьшить окно когда информация вообще доступна. (те время жизни ссылки в данном случае обычно измеряется минутами, максимум несколькими часами)
ну и при передаче ссылки и пароля через разные средства доставки информации, вероятность перехвата тоже сильно уменьшается.

TLS виконує весь процес генерації, обміну та перевірки ключів автоматично. І зберігати ніде не потрібно.

как вы представляете себе собственно организацию передачи при помощи него? попросите получателя поднять сервер на своей стороне?
ну и опять же вопрос в том что не всегда есть возможность организовать прямую связь между получателем и отправителем :)

Так як і https браузинг... У Вас же теж не прямий зв’язок між клієнтами. Тож два ТЛС з’єднання на сервер-посередник. Можливо одразу і перекидати байти з одного в інший. Чому ні?

Ну шифруйте с gpg в симметричном режиме и прикладывайте пароль вместе с файлом ))
Это не сильно будет отличатся от описанной схемы )

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

Подписаться на комментарии