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