Comments 46
Кто нибудь уже попробовал?
вы можете добавить в свое приложение надежное End-to-end шифрование или беспарольную аутентификацию всего лишь несколькими строками кода.
Хотелось бы подробнее, не «use case», как на сайте, а «success story».
Все же есть несколько вопросов. Интересно узнать принцип работы с токенами( не успел просмотреть полностью код ), реализовано через библиотеки xxPKCS11 или через APDU? Какие алгоритмы криптографические используются? Есть ли возможность к примеру выработать ключевую пару не только на токене но и в оперативки( временные ключи ). В целом идея конечно хорошая, сам долгое время занимаюсь решением данных вопросов( кроссплатформенная криптография ). Насколько мне известно на данный момент нет ничего действительно стоящего для работы с различными токенами на различных системах без привлечения инструментария разработчиков самих токенов( рутокен, etoken, jacarta и т.д. )
Добрый день alexeydevil, в качестве криптографической основы для доступа к сервисам Virgil Security, используется пара ассиметричных ключей. В данный момент мы не поддерживаем работу с токенами.
к сервисам Virgil Security
Дак созданное приложение может работать в полностью закрытой от внешнего интернета сети?
Условно говоря с ПК на ПК по 1 шлангу.
И поддерживаю этот комментарий, хочется подробностей!
А в моём вайбере так и не появился обещанный замочек
End-to-End шифрование через посредника? А смысл?
Смысл в том, чтобы избавить рядового разработчика от написания всей инфраструктуры для end-to-end encryption.
Virgil не является посредником, как таковым, шифрование происходит на стороне пользователя. У нас лишь хранятся открытые ключи.
Т.е. Вы по сути PKI с удобным API и множеством binding-ов к языкам программирования. Понятно.
Да, так же опенсоурс Crypto библиотекой, которая позволяет выполнять основные криптографические операции как generate keys, encrypt, sign, verity, decrypt.
В общем и целом да, но есть пара нюансов.
Во-первых, как вы правильно отметили мы поддерживаем множество языков программирования.
Во-вторых, в добавок к PKI мы предлагаем опенсорс библиотеку, реализующую большое количество современных криптоалгоритмов.
Наличие этих нюансов, хочется верить, избавляет нас от обидного ярлыка «посредник».:) Используя наш сервис разработчик способен реализовать именно end-to-end шифрование для своих пользователей. Генерация ключей происходит на устройстве пользователя. Публичный ключ перед загрузкой в хранилище заверяется разработчиком. Шифрование производится только с использованием аутентифицированного ВАШИМ приложением, а ни в коем случае не НАШИМ сервисом, ключа. Выполнение всех этих условий является обязательным и мы будем всячески напоминать об этом нашим разработчикам.
Во-первых, как вы правильно отметили мы поддерживаем множество языков программирования.
Во-вторых, в добавок к PKI мы предлагаем опенсорс библиотеку, реализующую большое количество современных криптоалгоритмов.
Наличие этих нюансов, хочется верить, избавляет нас от обидного ярлыка «посредник».:) Используя наш сервис разработчик способен реализовать именно end-to-end шифрование для своих пользователей. Генерация ключей происходит на устройстве пользователя. Публичный ключ перед загрузкой в хранилище заверяется разработчиком. Шифрование производится только с использованием аутентифицированного ВАШИМ приложением, а ни в коем случае не НАШИМ сервисом, ключа. Выполнение всех этих условий является обязательным и мы будем всячески напоминать об этом нашим разработчикам.
Звучит вкусно. Но раз уж вы пишете на хабр, может, предоставите отдельную статью с примерами кода, гитхаб репы с n (n>1) минимальными проектами на разных языках и платформах, которые спокойно коммуницируют между собой, используя ваше API? Я вижу юз-кейс примеры в описании API, но это не полноценные приложения, а скорее просто proof of concept.
Данная статья является вводной. В ближайшем будущем мы планируем ряд статей с примерами по внедрению end-to-end encryption в различные сервисы, такие как Twilio. Сейчас на сайте в Quickstart, SDK, Crypto есть ссылки на публичные репозитории, где можно на рабочем примере увидеть работу наших сервисов.
Вот ссылка на GitHub, где можно найти все репозитории Virgil Security.
Вот правильная ссылка, ваша ведёт на главную, https://github.com/VirgilSecurity
Сорри, был напуган ))) точно! Это правельная ссылка. https://github.com/VirgilSecurity
Здравствуйте, хотелось бы задать несколько вопросов:
1. Есть ли поддержка pgp?
2. У Вас java-android — на десктопе будет работать? (если зависимости на андроид апи)
3. Как управляется криптостойскость — есть ли аналоги «расширение до неограниченной юрисдикции» по аналогии в java.
4. Есть ли зависимости на java security, необходимо ли доставлять нативные dll или jar в дерево папок jvm (нестандартными методами в classpath).
Спасибо!
1. Есть ли поддержка pgp?
2. У Вас java-android — на десктопе будет работать? (если зависимости на андроид апи)
3. Как управляется криптостойскость — есть ли аналоги «расширение до неограниченной юрисдикции» по аналогии в java.
4. Есть ли зависимости на java security, необходимо ли доставлять нативные dll или jar в дерево папок jvm (нестандартными методами в classpath).
Спасибо!
Здравствуйте, Snecachan,
1. Нет, pgp не поддерживается (мы используем ECIES).
2. Нет, не будет, поскольку в сборке под Android отсутствуют нативные библиотеки под десктопные платформы (Windows, Linux, Mac os). Для не-Андроид рекомендуется использовать Virgil Client.
4. Зависимостей на Java security нет, мы используем собственную библиотеку Crypto. Нативные библиотеки упакованы в JAR, так что нет необходимости что-либо доставлять.
1. Нет, pgp не поддерживается (мы используем ECIES).
2. Нет, не будет, поскольку в сборке под Android отсутствуют нативные библиотеки под десктопные платформы (Windows, Linux, Mac os). Для не-Андроид рекомендуется использовать Virgil Client.
4. Зависимостей на Java security нет, мы используем собственную библиотеку Crypto. Нативные библиотеки упакованы в JAR, так что нет необходимости что-либо доставлять.
3. Криптостойкость управляется непосредственно разработчиком конечного продукта, посредством выбора (ограничения выбора) ключей, которые генерируется в его приложении. Решения аналогичного в Java нет, поэтому ответственность за соблюдение криптографических ограничений, на данный момент, лежит полностью на разработчике.
From 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'
А что так наши алгоритмы однобоко представлены? Только один ГОСТ 28147-89, а Стрибог с Кузнечиком и подпись?
Новые вопросы! ))
«Pricing» у вас есть, а где же «Terms&Conditions»? Хоть какие-нибудь гарантии задекларированы?
«Pricing» у вас есть, а где же «Terms&Conditions»? Хоть какие-нибудь гарантии задекларированы?
Вопросы более, чем приветствуются и мы рады вашему интересу.
Что касается Pricing, как видите, на данный момент все бесплатно и в открытом доступе наш код. Но у нас, безусловно, есть Terms of Service и Privacy Policy.
Что касается Pricing, как видите, на данный момент все бесплатно и в открытом доступе наш код. Но у нас, безусловно, есть Terms of Service и Privacy Policy.
Начинание конечно хорошее, но я буду вынужден выступить с его достаточно жёсткой критикой.
1) «Вы когда-нибудь задумывались почему безопасность до сих пор остается такой серьезной проблемой?
Если кратко, то в основном по четырем причинам:»
Совсем не так. Хоть это и прозвучит как тавтология, но безопасность должна в первую очередь быть именно БЕЗОПАСНОЙ. Ни удобной, ни кроссплатформенной, ни какой либо ещё, а именно безопасной. Именно поэтому любые решения класса «простой в использовании чёрный ящик» порочны априори. Ведь в реальности никто толком не будет в него заглядывать. Ну и привет закладкам и т.п. Да, формально это открытый код и любой вроде может. Но реально то что? Много людей проверяют код той-же OpenSSL? На этой ноте перейду к следующему пункту.
2) «Более того, мы написали очень много кода»
В шифровании кода должно быть мало, очень мало. Нужно стремиться сделать только самый необходимый минимум возможностей, режимов и т.д. Ведь для того чтобы наша безопасность и правда стала безопасной этот код должен проверяться большинством тех, кто его использует. Чем этот код меньше, тем легче его проверять. По хорошему он ещё должен быть ОЧЕНЬ хорошо документирован. Вообще если взять основу из сцепки RSA, DHE и AES-CTR/GCM (сюда же хеши, скажем SHA256/512 и генератор случайных чисел), то донести принципы его работы до каждого разработчика должно быть не очень сложно. Просто объяснять нужно максимально доступно. Без понимания не будет никакой безопасности, а будет лишь видимость. Видимость же безопасности куда хуже чем её явное отсутствие.
3) «Вместо этого мы предоставляем гибкую инфраструктуру»
Чем сущность больше, тем выше вероятность ошибок и сложнее доказать их отсутствие.
4) «Мы реализовали большинство современных эллиптических кривых и вы можете использовать любую из них»
Использование элиптики это спорное решение. Порог понимания у элиптики куда выше, как следствие кол-во людей способных полноценно её понимать меньше. Моё глубокое ИМХО, что время для неё ещё не наступило. Но ещё раз повторюсь, это только моё личное мнение.
5) «Вам необходимо менять алгоритм каждый час? Каждую минуту?»
Зачем? Алгоритм или надёжный, тогда меняют только ключи, или нет, тогда зачем он нужен?
6) «К сожалению, наиболее уязвимым местом в любой системе по прежнему остаются пользователи.»
Именно поэтому единственный путь это их просвящение. Никакая серебряная пуля эту проблему не решит.
7) «использовать глобальную инфраструктуру открытых ключей»
Ну и сама тема ключей, сертификатов и собственно самого доверия очень обширна и сложна. В рамках комментария я не готов давать развёрнутый ответ на ней.
P.S. И самый главный вопрос — вопрос доверия к вам. Не поймите меня не правильно, я лично против вас ничего не имею, но обоснованно не доверяю никому кто обещает мне решить мои проблемы, особенно в сфере безопасности, за просто так. Слишком велик соблазн…
1) «Вы когда-нибудь задумывались почему безопасность до сих пор остается такой серьезной проблемой?
Если кратко, то в основном по четырем причинам:»
Совсем не так. Хоть это и прозвучит как тавтология, но безопасность должна в первую очередь быть именно БЕЗОПАСНОЙ. Ни удобной, ни кроссплатформенной, ни какой либо ещё, а именно безопасной. Именно поэтому любые решения класса «простой в использовании чёрный ящик» порочны априори. Ведь в реальности никто толком не будет в него заглядывать. Ну и привет закладкам и т.п. Да, формально это открытый код и любой вроде может. Но реально то что? Много людей проверяют код той-же OpenSSL? На этой ноте перейду к следующему пункту.
2) «Более того, мы написали очень много кода»
В шифровании кода должно быть мало, очень мало. Нужно стремиться сделать только самый необходимый минимум возможностей, режимов и т.д. Ведь для того чтобы наша безопасность и правда стала безопасной этот код должен проверяться большинством тех, кто его использует. Чем этот код меньше, тем легче его проверять. По хорошему он ещё должен быть ОЧЕНЬ хорошо документирован. Вообще если взять основу из сцепки RSA, DHE и AES-CTR/GCM (сюда же хеши, скажем SHA256/512 и генератор случайных чисел), то донести принципы его работы до каждого разработчика должно быть не очень сложно. Просто объяснять нужно максимально доступно. Без понимания не будет никакой безопасности, а будет лишь видимость. Видимость же безопасности куда хуже чем её явное отсутствие.
3) «Вместо этого мы предоставляем гибкую инфраструктуру»
Чем сущность больше, тем выше вероятность ошибок и сложнее доказать их отсутствие.
4) «Мы реализовали большинство современных эллиптических кривых и вы можете использовать любую из них»
Использование элиптики это спорное решение. Порог понимания у элиптики куда выше, как следствие кол-во людей способных полноценно её понимать меньше. Моё глубокое ИМХО, что время для неё ещё не наступило. Но ещё раз повторюсь, это только моё личное мнение.
5) «Вам необходимо менять алгоритм каждый час? Каждую минуту?»
Зачем? Алгоритм или надёжный, тогда меняют только ключи, или нет, тогда зачем он нужен?
6) «К сожалению, наиболее уязвимым местом в любой системе по прежнему остаются пользователи.»
Именно поэтому единственный путь это их просвящение. Никакая серебряная пуля эту проблему не решит.
7) «использовать глобальную инфраструктуру открытых ключей»
Ну и сама тема ключей, сертификатов и собственно самого доверия очень обширна и сложна. В рамках комментария я не готов давать развёрнутый ответ на ней.
P.S. И самый главный вопрос — вопрос доверия к вам. Не поймите меня не правильно, я лично против вас ничего не имею, но обоснованно не доверяю никому кто обещает мне решить мои проблемы, особенно в сфере безопасности, за просто так. Слишком велик соблазн…
Здравствуйте!
Прежде всего позвольте поблагодарить за развернутый комментарий. Мы очень хорошо относимся к аргументированной критике и одной из причин нашего появления на Хабре было как раз таки желание выслашать как можно больше точек зрения.
Вы совершенно правы. Безопасность не имеет пограничных состояний. Безопасность либо есть либо ее, простите, нет. Но скажите, разве удобство системы снижает вероятность ее безопасности? Мы уверены что одно не противоречит другому и стремимся достичь двух различных целей: безопасность наших решений и простота и удобство их использования. Обратите внимание, мы предлагаем вовсе не «черный ящик». Все наши протоколы и исходные коды совершенно открыты.
Пример OpenSSL в этом плане весьма показателен. Благодаря открытому исходному коду исследователям удалось найти не одну критическую уязвимость: раз, два, три.
И в этом вашем утверждении все совершенно правильно, поэтому наша криптобиблиотека содержит тот самый необходимым минимум, о котором вы говорите. А большое количество SDK делают возможным использование этого минимума на разных языках и платформах.
У криптографии на эллиптических кривых есть большое преимущество, связанное с размерами ключей и подписи. Для обеспечения приемлемого уровня стойкости в 128 бит вам потребуется 3072 битный RSA ключ или 256 битный ECDSA. Принимая во внимание закон Мура можно сказать, что использование RSA может оказаться в будущем слишком хлопотным делом.
Нужно принимать во внимание, что надежный сегодня алгоритм, завтра может оказаться фатально уязвимым.
И это абсолютно правильно! Мы сами никому не доверяем, поэтому и создали свой собственный сервис с блэкджеком и Curve25519:) Мы и не хотим, чтобы нам доверяли. Вы вполне можете использовать наш PKI, но при никогда не предавать нам своих приватных ключей. Более того, при этом вы можете даже подписывать ключи своей собственной реализацией RSA и отвергать все ключи лишенные вашей подписи.
Прежде всего позвольте поблагодарить за развернутый комментарий. Мы очень хорошо относимся к аргументированной критике и одной из причин нашего появления на Хабре было как раз таки желание выслашать как можно больше точек зрения.
Совсем не так. Хоть это и прозвучит как тавтология, но безопасность должна в первую очередь быть именно БЕЗОПАСНОЙ. Ни удобной, ни кроссплатформенной, ни какой либо ещё, а именно безопасной.
Вы совершенно правы. Безопасность не имеет пограничных состояний. Безопасность либо есть либо ее, простите, нет. Но скажите, разве удобство системы снижает вероятность ее безопасности? Мы уверены что одно не противоречит другому и стремимся достичь двух различных целей: безопасность наших решений и простота и удобство их использования. Обратите внимание, мы предлагаем вовсе не «черный ящик». Все наши протоколы и исходные коды совершенно открыты.
Много людей проверяют код той-же OpenSSL?
Пример OpenSSL в этом плане весьма показателен. Благодаря открытому исходному коду исследователям удалось найти не одну критическую уязвимость: раз, два, три.
В шифровании кода должно быть мало, очень мало. Нужно стремиться сделать только самый необходимый минимум возможностей, режимов и т.д.
И в этом вашем утверждении все совершенно правильно, поэтому наша криптобиблиотека содержит тот самый необходимым минимум, о котором вы говорите. А большое количество SDK делают возможным использование этого минимума на разных языках и платформах.
Использование элиптики это спорное решение.
У криптографии на эллиптических кривых есть большое преимущество, связанное с размерами ключей и подписи. Для обеспечения приемлемого уровня стойкости в 128 бит вам потребуется 3072 битный RSA ключ или 256 битный ECDSA. Принимая во внимание закон Мура можно сказать, что использование RSA может оказаться в будущем слишком хлопотным делом.
Зачем? Алгоритм или надёжный, тогда меняют только ключи, или нет, тогда зачем он нужен?
Нужно принимать во внимание, что надежный сегодня алгоритм, завтра может оказаться фатально уязвимым.
я лично против вас ничего не имею, но обоснованно не доверяю никому кто обещает мне решить мои проблемы, особенно в сфере безопасности, за просто так.
И это абсолютно правильно! Мы сами никому не доверяем, поэтому и создали свой собственный сервис с блэкджеком и Curve25519:) Мы и не хотим, чтобы нам доверяли. Вы вполне можете использовать наш PKI, но при никогда не предавать нам своих приватных ключей. Более того, при этом вы можете даже подписывать ключи своей собственной реализацией RSA и отвергать все ключи лишенные вашей подписи.
Не увидел в списке поддерживаемых языков любимого всеми студентами Delphi, вы про него не забыли или забили?
UFO just landed and posted this here
Куда вам столько кривых? Я бы наоборот выкинул всё, кроме 25519, потому что только она соответствует критериям безопасности, дуракоустойчивости (любой массив в 32 байта является валидным ключом) и скорости. Это самая быстрая из всех безопасных кривых, к тому же не профинансирована государством.
UFO just landed and posted this here
Не понял вашего комментария про 128 бит. Это мало, вы считаете?
UFO just landed and posted this here
Если лет на 5-10, то пора во всю внедрять post-quantum crypto, тем более, что его уже во всю разрабатывают
UFO just landed and posted this here
Не соглашусь. Там ежегодные конференции проводятся, это одна из самых горячих тем в последние годы. Даже уже выпустили рекомендации по используемым алгоритмам и параметрам
McEliece, например, создан в 1978 году и до сих пор ничего на него не накопали. Там просто ключи везде большие, поэтому алгоритмы непопулярны в широких кругах
Но то, что для симметричных алгоритмов рекомендуют 256 бит это да, правда тоже «на всякий случай». Прям утверждений, что после появления квантовых компов безопасность симметричных алгоритмов драматично упадет, нет
McEliece, например, создан в 1978 году и до сих пор ничего на него не накопали. Там просто ключи везде большие, поэтому алгоритмы непопулярны в широких кругах
Но то, что для симметричных алгоритмов рекомендуют 256 бит это да, правда тоже «на всякий случай». Прям утверждений, что после появления квантовых компов безопасность симметричных алгоритмов драматично упадет, нет
А NIST SP 800-90A у вас с дыркой?
Данный алгоритм реализован как часть библиотеки MbedTLS — https://tls.mbed.org/ctr-drbg-source-code
На дынный момент уязвимостей в данном модуле не найдено — https://tls.mbed.org/security
Sign up to leave a comment.
End-to-end шифрование, теперь это просто