Шифрование. Вопрос, к которому многие разработчики подходят с благоговением и опаской. За последние пару десятков лет многие пытались изменить этот неидеальный мир и многие достигали успеха. Но одна вещь оставалась неизменной — создать безопасное приложение до сих пор могут позволить себе далеко не все. Цена безопасности слишком велика и включает в себя изучение десятков стандартов и спецификаций, компиляцию тонн непонятного кода, чтение многостраничных монографий криптографических гуру. Мы в Virgil Security далеки от амбициозных планов по изменению мира, мы просто хотим сделать безопасность доступной каждому. И вот мы на Хабре, здравствуйте!
Идея о доступном, безопасном способе обмена информацией витала в воздухе уже давно. Но, к сожалению, на протяжении многих лет она оставалась всего лишь мечтой наряду с летающими автомобилями и высадкой на Марс. Мы предлагаем каждому разработчику простой и надежный способ сделать эту мечту явью. Как? Вот об этом мы и собираемся рассказать.
Итак, что же мы предлагаем? Мы предлагаем инфраструктуру, позволяющую сделать из любого разработчика опытного криптографа. Независимо от языка, на котором вы пишите, будь то C, C++, C#, ObjectiveC, Swift, JavaScript, Go, PHP, Python, Ruby или что-то другое. Независимо от типа создаваемого вами продукта: десктопное или мобильное приложение, облачный сервис или встраиваемая система. Независимо от операционной системы, на которой вы работаете: Windows, MacOS, Linux, iOS. С помощью Virgil Security вы можете добавить в свое приложение надежное End-to-end шифрование или беспарольную аутентификацию всего лишь несколькими строками кода.
Вы когда-нибудь задумывались почему безопасность до сих пор остается такой серьезной проблемой?
Если кратко, то в основном по четырем причинам:
- Отсутствие качественной, кроссплатформенной реализации криптоалгоритмов;
- Отсутствие инфраструктуры, позволяющей сделать криптографию повсеместной;
- Проблема совместимости. Внедряя шифрование в свой продукт, разработчики вынуждены жертвовать совместимостью своих решений;
- Отсутствие гибкой системы управления ключами.
И мы думаем, что у нас есть способ решить все эти проблемы раз и навсегда.
Во-первых: Исторически сложилось так, что мир криптографов и мир программистов ПО практически не пересекался. В результате чего сегодня доступно большое количество самых разных криптографических библиотек и инструментов, которые бесполезны для большинства разработчиков в силу своей сложности и раздробленности. Мы сконцентрировали свои усилия на создании единого API, использование которого позволит разработчику добавить стойкое шифрование к своему проекту всего за несколько минут. Более того, мы написали очень много кода, чтобы сделать использование API возможным практически на каждом языке программирования. И весь этот код мы опубликовали в открытом доступе под BSD-3 лицензией.
Во-вторых: Создавать систему, которая использует определенные алгоритмы или имеет ограниченную функциональность – это значит повторять ошибки последних 20 лет. Вместо этого мы предоставляем гибкую инфраструктуру, с помощью которой вы можете устанавливать метод шифрования для каждого сообщения, файла или пакета. Мы реализовали большинство современных эллиптических кривых и вы можете использовать любую из них. Вам необходимо менять алгоритм каждый час? Каждую минуту? После каждого зашифрованного сообщения? Не проблема. Вы можете строить многослойное шифрование наподобие RSA+ECIES. И все это всего в несколько строк кода.
В-третьих: Совместимость. Несмотря на то, что многие современные языки имеют встроенную реализацию наиболее распространенных криптоалгоритмов, писать программы для Интернета Вещей, где данные могут считываться с датчиков и обрабатываться на Android и iOS устройствах, может оказаться весьма болезненным занятием. Virgil Security избавляет от подобных проблем. Мы предоставляем единый API, который будет работать на любой платформе.
В-четвертых: К сожалению, наиболее уязвимым местом в любой системе по прежнему остаются пользователи. Не все пользователи умеют грамотно управлять ключами, более того, пользователи могут вообще не подозревать о наличии ключей. Virgil Security предоставляет возможность не только использовать глобальную инфраструктуру открытых ключей, но также создать свою собственную локальную инфраструктуру, доступную в рамках одного приложения. Разработчик может разрешить пользователям сохранять зашифрованные копии ключей в хранилище приватных ключей, что гарантирует восстанавливаемость данных в случае утраты ключа.
Итак, как и говорилось выше, мы не пытаемся изменить мир. Мы предлагаем вам простой способ реализовать надежное шифрование и добавить его в ваш проект. Изменить мир и сделать его безопаснее способен каждый. Что для этого нужно сделать? Выбрать красную таблетку, разумеется.
Комментарии (45)
alexeydevil
13.05.2016 11:54Все же есть несколько вопросов. Интересно узнать принцип работы с токенами( не успел просмотреть полностью код ), реализовано через библиотеки xxPKCS11 или через APDU? Какие алгоритмы криптографические используются? Есть ли возможность к примеру выработать ключевую пару не только на токене но и в оперативки( временные ключи ). В целом идея конечно хорошая, сам долгое время занимаюсь решением данных вопросов( кроссплатформенная криптография ). Насколько мне известно на данный момент нет ничего действительно стоящего для работы с различными токенами на различных системах без привлечения инструментария разработчиков самих токенов( рутокен, etoken, jacarta и т.д. )
denzzel
13.05.2016 12:28Добрый день alexeydevil, в качестве криптографической основы для доступа к сервисам Virgil Security, используется пара ассиметричных ключей. В данный момент мы не поддерживаем работу с токенами.
Godless
13.05.2016 12:54к сервисам Virgil Security
Дак созданное приложение может работать в полностью закрытой от внешнего интернета сети?
Условно говоря с ПК на ПК по 1 шлангу.
И поддерживаю этот комментарий, хочется подробностей!
sseroshtan
13.05.2016 13:02+1Можно, если ПК1 содержит открытую часть ключа ПК2, и наоборот.
Зачастую вся соль заключается в том, что нужно зашифровать данные для конечного пользователя зная один из его идентификаторов, например email.
KonstantinSpb
13.05.2016 16:17End-to-End шифрование через посредника? А смысл?
denzzel
13.05.2016 16:38Смысл в том, чтобы избавить рядового разработчика от написания всей инфраструктуры для end-to-end encryption.
VirgilSecurity
13.05.2016 19:14Virgil не является посредником, как таковым, шифрование происходит на стороне пользователя. У нас лишь хранятся открытые ключи.
KonstantinSpb
13.05.2016 19:17+1Т.е. Вы по сути PKI с удобным API и множеством binding-ов к языкам программирования. Понятно.
denzzel
13.05.2016 20:03Да, так же опенсоурс Crypto библиотекой, которая позволяет выполнять основные криптографические операции как generate keys, encrypt, sign, verity, decrypt.
NeverWalkAloner
13.05.2016 21:39+1В общем и целом да, но есть пара нюансов.
Во-первых, как вы правильно отметили мы поддерживаем множество языков программирования.
Во-вторых, в добавок к PKI мы предлагаем опенсорс библиотеку, реализующую большое количество современных криптоалгоритмов.
Наличие этих нюансов, хочется верить, избавляет нас от обидного ярлыка «посредник».:) Используя наш сервис разработчик способен реализовать именно end-to-end шифрование для своих пользователей. Генерация ключей происходит на устройстве пользователя. Публичный ключ перед загрузкой в хранилище заверяется разработчиком. Шифрование производится только с использованием аутентифицированного ВАШИМ приложением, а ни в коем случае не НАШИМ сервисом, ключа. Выполнение всех этих условий является обязательным и мы будем всячески напоминать об этом нашим разработчикам.
Amareis
13.05.2016 16:17+3Звучит вкусно. Но раз уж вы пишете на хабр, может, предоставите отдельную статью с примерами кода, гитхаб репы с n (n>1) минимальными проектами на разных языках и платформах, которые спокойно коммуницируют между собой, используя ваше API? Я вижу юз-кейс примеры в описании API, но это не полноценные приложения, а скорее просто proof of concept.
NeverWalkAloner
13.05.2016 21:47+1Не спешите, мы пока еще только поздоровались.) Мы люди скромные и посчитали, что было бы невежливо кидаться с порога кусками кода.
В этом блоге мы планируем выкладывать и код и примеры и даже объяснения тех или иных решений. В общем подождите чуть-чуть, дальше, мы надеемся, будет интереснее.
denzzel
13.05.2016 16:54+1Данная статья является вводной. В ближайшем будущем мы планируем ряд статей с примерами по внедрению end-to-end encryption в различные сервисы, такие как Twilio. Сейчас на сайте в Quickstart, SDK, Crypto есть ссылки на публичные репозитории, где можно на рабочем примере увидеть работу наших сервисов.
Вот ссылка на GitHub, где можно найти все репозитории Virgil Security.Amareis
13.05.2016 18:43+1Вот правильная ссылка, ваша ведёт на главную, https://github.com/VirgilSecurity
denzzel
13.05.2016 18:59Сорри, был напуган ))) точно! Это правельная ссылка. https://github.com/VirgilSecurity
Snecachan
13.05.2016 21:13Здравствуйте, хотелось бы задать несколько вопросов:
1. Есть ли поддержка pgp?
2. У Вас java-android — на десктопе будет работать? (если зависимости на андроид апи)
3. Как управляется криптостойскость — есть ли аналоги «расширение до неограниченной юрисдикции» по аналогии в java.
4. Есть ли зависимости на java security, необходимо ли доставлять нативные dll или jar в дерево папок jvm (нестандартными методами в classpath).
Спасибо!VirgilSecurity
15.05.2016 01:14Здравствуйте, Snecachan,
1. Нет, pgp не поддерживается (мы используем ECIES).
2. Нет, не будет, поскольку в сборке под Android отсутствуют нативные библиотеки под десктопные платформы (Windows, Linux, Mac os). Для не-Андроид рекомендуется использовать Virgil Client.
4. Зависимостей на Java security нет, мы используем собственную библиотеку Crypto. Нативные библиотеки упакованы в JAR, так что нет необходимости что-либо доставлять.
sseroshtan
15.05.2016 12:313. Криптостойкость управляется непосредственно разработчиком конечного продукта, посредством выбора (ограничения выбора) ключей, которые генерируется в его приложении. Решения аналогичного в Java нет, поэтому ответственность за соблюдение криптографических ограничений, на данный момент, лежит полностью на разработчике.
sseroshtan
20.05.2016 12:32From the Java/Android documentation
Java Desktop — Maven:
<dependencies> <dependency> <groupId>com.virgilsecurity.sdk</groupId> <artifactId>client</artifactId> <version>3.2.0</version> </dependency> </dependencies>
Java Android — Gradle:
compile 'com.virgilsecurity.sdk:android:3.2.0@aar' compile 'com.squareup.retrofit2:retrofit:2.0.0' compile 'com.squareup.retrofit2:converter-gson:2.0.0'
ru_crypt
13.05.2016 19:35А что так наши алгоритмы однобоко представлены? Только один ГОСТ 28147-89, а Стрибог с Кузнечиком и подпись?
VirgilSecurity
13.05.2016 19:51Будем добавлять ГОСТы по мере надобности. Пока что дефолтный — Curve25519.
tmnhy
13.05.2016 23:00Новые вопросы! ))
«Pricing» у вас есть, а где же «Terms&Conditions»? Хоть какие-нибудь гарантии задекларированы?
VirgilSecurity
13.05.2016 23:10Вопросы более, чем приветствуются и мы рады вашему интересу.
Что касается Pricing, как видите, на данный момент все бесплатно и в открытом доступе наш код. Но у нас, безусловно, есть Terms of Service и Privacy Policy.
Komei
14.05.2016 03:51+2Начинание конечно хорошее, но я буду вынужден выступить с его достаточно жёсткой критикой.
1) «Вы когда-нибудь задумывались почему безопасность до сих пор остается такой серьезной проблемой?
Если кратко, то в основном по четырем причинам:»
Совсем не так. Хоть это и прозвучит как тавтология, но безопасность должна в первую очередь быть именно БЕЗОПАСНОЙ. Ни удобной, ни кроссплатформенной, ни какой либо ещё, а именно безопасной. Именно поэтому любые решения класса «простой в использовании чёрный ящик» порочны априори. Ведь в реальности никто толком не будет в него заглядывать. Ну и привет закладкам и т.п. Да, формально это открытый код и любой вроде может. Но реально то что? Много людей проверяют код той-же OpenSSL? На этой ноте перейду к следующему пункту.
2) «Более того, мы написали очень много кода»
В шифровании кода должно быть мало, очень мало. Нужно стремиться сделать только самый необходимый минимум возможностей, режимов и т.д. Ведь для того чтобы наша безопасность и правда стала безопасной этот код должен проверяться большинством тех, кто его использует. Чем этот код меньше, тем легче его проверять. По хорошему он ещё должен быть ОЧЕНЬ хорошо документирован. Вообще если взять основу из сцепки RSA, DHE и AES-CTR/GCM (сюда же хеши, скажем SHA256/512 и генератор случайных чисел), то донести принципы его работы до каждого разработчика должно быть не очень сложно. Просто объяснять нужно максимально доступно. Без понимания не будет никакой безопасности, а будет лишь видимость. Видимость же безопасности куда хуже чем её явное отсутствие.
3) «Вместо этого мы предоставляем гибкую инфраструктуру»
Чем сущность больше, тем выше вероятность ошибок и сложнее доказать их отсутствие.
4) «Мы реализовали большинство современных эллиптических кривых и вы можете использовать любую из них»
Использование элиптики это спорное решение. Порог понимания у элиптики куда выше, как следствие кол-во людей способных полноценно её понимать меньше. Моё глубокое ИМХО, что время для неё ещё не наступило. Но ещё раз повторюсь, это только моё личное мнение.
5) «Вам необходимо менять алгоритм каждый час? Каждую минуту?»
Зачем? Алгоритм или надёжный, тогда меняют только ключи, или нет, тогда зачем он нужен?
6) «К сожалению, наиболее уязвимым местом в любой системе по прежнему остаются пользователи.»
Именно поэтому единственный путь это их просвящение. Никакая серебряная пуля эту проблему не решит.
7) «использовать глобальную инфраструктуру открытых ключей»
Ну и сама тема ключей, сертификатов и собственно самого доверия очень обширна и сложна. В рамках комментария я не готов давать развёрнутый ответ на ней.
P.S. И самый главный вопрос — вопрос доверия к вам. Не поймите меня не правильно, я лично против вас ничего не имею, но обоснованно не доверяю никому кто обещает мне решить мои проблемы, особенно в сфере безопасности, за просто так. Слишком велик соблазн…VirgilSecurity
14.05.2016 08:21Здравствуйте!
Прежде всего позвольте поблагодарить за развернутый комментарий. Мы очень хорошо относимся к аргументированной критике и одной из причин нашего появления на Хабре было как раз таки желание выслашать как можно больше точек зрения.
Совсем не так. Хоть это и прозвучит как тавтология, но безопасность должна в первую очередь быть именно БЕЗОПАСНОЙ. Ни удобной, ни кроссплатформенной, ни какой либо ещё, а именно безопасной.
Вы совершенно правы. Безопасность не имеет пограничных состояний. Безопасность либо есть либо ее, простите, нет. Но скажите, разве удобство системы снижает вероятность ее безопасности? Мы уверены что одно не противоречит другому и стремимся достичь двух различных целей: безопасность наших решений и простота и удобство их использования. Обратите внимание, мы предлагаем вовсе не «черный ящик». Все наши протоколы и исходные коды совершенно открыты.
Много людей проверяют код той-же OpenSSL?
Пример OpenSSL в этом плане весьма показателен. Благодаря открытому исходному коду исследователям удалось найти не одну критическую уязвимость: раз, два, три.
В шифровании кода должно быть мало, очень мало. Нужно стремиться сделать только самый необходимый минимум возможностей, режимов и т.д.
И в этом вашем утверждении все совершенно правильно, поэтому наша криптобиблиотека содержит тот самый необходимым минимум, о котором вы говорите. А большое количество SDK делают возможным использование этого минимума на разных языках и платформах.
Использование элиптики это спорное решение.
У криптографии на эллиптических кривых есть большое преимущество, связанное с размерами ключей и подписи. Для обеспечения приемлемого уровня стойкости в 128 бит вам потребуется 3072 битный RSA ключ или 256 битный ECDSA. Принимая во внимание закон Мура можно сказать, что использование RSA может оказаться в будущем слишком хлопотным делом.
Зачем? Алгоритм или надёжный, тогда меняют только ключи, или нет, тогда зачем он нужен?
Нужно принимать во внимание, что надежный сегодня алгоритм, завтра может оказаться фатально уязвимым.
я лично против вас ничего не имею, но обоснованно не доверяю никому кто обещает мне решить мои проблемы, особенно в сфере безопасности, за просто так.
И это абсолютно правильно! Мы сами никому не доверяем, поэтому и создали свой собственный сервис с блэкджеком и Curve25519:) Мы и не хотим, чтобы нам доверяли. Вы вполне можете использовать наш PKI, но при никогда не предавать нам своих приватных ключей. Более того, при этом вы можете даже подписывать ключи своей собственной реализацией RSA и отвергать все ключи лишенные вашей подписи.
Sleuthhound
14.05.2016 15:11Не увидел в списке поддерживаемых языков любимого всеми студентами Delphi, вы про него не забыли или забили?
denzzel
14.05.2016 17:09))) Ну тут спорный вопрос, нынче студенты модные стали им JS, C#, Python подавай. Ну а если серьезно то пока Delphi мы не планировали поддерживать.
Ivan_83
16.05.2016 15:091. Миры вполне себе пересекаются, но для работы с криптой всё равно требуется хотя бы минимальное понимание вопроса.
Никакие либы не спасут от прогеров которые применяют крипту не правильно в виду отсутствия знаний.
Примеров можно приводить кучи.
Это и Reply атаки, когда прогер не предусмотрел что один пакет может приходить много раз, и еве достаточно собрать коллекцию валидных пакетов и слать их когда нужно, и атаки на расширение хэша и прочие.
Я бы брал LibreSSL и не парился с вашей либой. Может быть более экзотичные NaCl.
2. Кривых маловато.
Позор что нет наших из ГОСТа, правда под них нужно чуточку править рассчёты. Делов на пол дня с тестами.
Многослойное шифрование называется каскадом.
Более того, есть определённые случаи когда каскад хуже: https://www.pgpru.com/novosti/2015/xorkombinirovanieheshfunkcijjsnizhaetihstojjkostj
3. Для всяких безмозглых железок с оч ограниченными ресурсами есть свои либы, особенно там проблематично с ECDSA, сомневаюсь что ваша либо сможет пахать на чём то более убогом чем х86/арм/мипс, где например деления или умножения нет или адрес в 16 бит.
4. Начали за здравие программистов кончили за упокой пользователей.
Не нужна инфраструктура, не поможет она никому.
Нужен PGP/P2P без серверов, обычная сеть доверия, и нужно чтобы со школы этим учили пользоваться.
А NIST SP 800-90A у вас с дыркой?
https://en.wikipedia.org/wiki/NIST_SP_800-90A
Scratch
19.05.2016 06:57+2Куда вам столько кривых? Я бы наоборот выкинул всё, кроме 25519, потому что только она соответствует критериям безопасности, дуракоустойчивости (любой массив в 32 байта является валидным ключом) и скорости. Это самая быстрая из всех безопасных кривых, к тому же не профинансирована государством.
Ivan_83
19.05.2016 11:56+1Пусть будет выбор.
Лично я бы предпочёл бы использовать сразу несколько разных.
Только у неё заявленный уровень безопасности 128 бит, также как и у чачи20.
По поводу быстроты:
1. не факт что эта быстрота нужна, тем более в п2п
2. ECDSA тоже может работать довольно быстро
В криптографии дуракам не место. Одно из немногих мест где это сразу приводит к фейлам.
Смотрю там в табличке много всего нового появилось.
Но с RNG конечно оч интересно, сделали они там Dual_EC_DRBG или нет и если да то откуда брали параметры.Scratch
19.05.2016 13:06Не понял вашего комментария про 128 бит. Это мало, вы считаете?
Ivan_83
19.05.2016 15:40+1Да, я считаю что 128 бит и всего один криптоалгоритм это маловато, если смотреть в будущее лет на 5-10.
Но для текущих задач оно пока приемлемо, типа по SSH или TLS куда то слазать, с учётом того что за 5-10 лет эта инфа при расшифровке потеряет актуальность.
Те использовать смысл есть, а вот закладываться на это как единственный алгоритм на ближайшее будущее не стоит.Scratch
19.05.2016 17:22+1Если лет на 5-10, то пора во всю внедрять post-quantum crypto, тем более, что его уже во всю разрабатывают
Ivan_83
19.05.2016 17:36+1Не пора, его ещё нет.
Всё что есть это исследования, которые ещё не сильно то и подвергались классическому криптоанализу.
С другой стороны пачка разных алгоритмов на разных ключах даёт как высокую алгоритмическую сложность сама по себе так и длинный ключ, так что в итоге придётся сильно повозится даже на квантовом компьютере, если/когда он появится.Scratch
20.05.2016 09:39+1Не соглашусь. Там ежегодные конференции проводятся, это одна из самых горячих тем в последние годы. Даже уже выпустили рекомендации по используемым алгоритмам и параметрам
McEliece, например, создан в 1978 году и до сих пор ничего на него не накопали. Там просто ключи везде большие, поэтому алгоритмы непопулярны в широких кругах
Но то, что для симметричных алгоритмов рекомендуют 256 бит это да, правда тоже «на всякий случай». Прям утверждений, что после появления квантовых компов безопасность симметричных алгоритмов драматично упадет, нет
newday
Кто нибудь уже попробовал?