End-to-end шифрование, теперь это просто


    Шифрование. Вопрос, к которому многие разработчики подходят с благоговением и опаской. За последние пару десятков лет многие пытались изменить этот неидеальный мир и многие достигали успеха. Но одна вещь оставалась неизменной — создать безопасное приложение до сих пор могут позволить себе далеко не все. Цена безопасности слишком велика и включает в себя изучение десятков стандартов и спецификаций, компиляцию тонн непонятного кода, чтение многостраничных монографий криптографических гуру. Мы в Virgil Security далеки от амбициозных планов по изменению мира, мы просто хотим сделать безопасность доступной каждому. И вот мы на Хабре, здравствуйте!

    Идея о доступном, безопасном способе обмена информацией витала в воздухе уже давно. Но, к сожалению, на протяжении многих лет она оставалась всего лишь мечтой наряду с летающими автомобилями и высадкой на Марс. Мы предлагаем каждому разработчику простой и надежный способ сделать эту мечту явью. Как? Вот об этом мы и собираемся рассказать.
    Звучит круто, к черту подробности, я хочу немного безопасности прямо сейчас!
    Вам на страницу с описанием Virgil API.


    Итак, что же мы предлагаем? Мы предлагаем инфраструктуру, позволяющую сделать из любого разработчика опытного криптографа. Независимо от языка, на котором вы пишите, будь то C, C++, C#, ObjectiveC, Swift, JavaScript, Go, PHP, Python, Ruby или что-то другое. Независимо от типа создаваемого вами продукта: десктопное или мобильное приложение, облачный сервис или встраиваемая система. Независимо от операционной системы, на которой вы работаете: Windows, MacOS, Linux, iOS. С помощью Virgil Security вы можете добавить в свое приложение надежное End-to-end шифрование или беспарольную аутентификацию всего лишь несколькими строками кода.

    Вы когда-нибудь задумывались почему безопасность до сих пор остается такой серьезной проблемой?
    Если кратко, то в основном по четырем причинам:
    1. Отсутствие качественной, кроссплатформенной реализации криптоалгоритмов;
    2. Отсутствие инфраструктуры, позволяющей сделать криптографию повсеместной;
    3. Проблема совместимости. Внедряя шифрование в свой продукт, разработчики вынуждены жертвовать совместимостью своих решений;
    4. Отсутствие гибкой системы управления ключами.

    И мы думаем, что у нас есть способ решить все эти проблемы раз и навсегда.

    Во-первых: Исторически сложилось так, что мир криптографов и мир программистов ПО практически не пересекался. В результате чего сегодня доступно большое количество самых разных криптографических библиотек и инструментов, которые бесполезны для большинства разработчиков в силу своей сложности и раздробленности. Мы сконцентрировали свои усилия на создании единого API, использование которого позволит разработчику добавить стойкое шифрование к своему проекту всего за несколько минут. Более того, мы написали очень много кода, чтобы сделать использование API возможным практически на каждом языке программирования. И весь этот код мы опубликовали в открытом доступе под BSD-3 лицензией.

    Во-вторых: Создавать систему, которая использует определенные алгоритмы или имеет ограниченную функциональность – это значит повторять ошибки последних 20 лет. Вместо этого мы предоставляем гибкую инфраструктуру, с помощью которой вы можете устанавливать метод шифрования для каждого сообщения, файла или пакета. Мы реализовали большинство современных эллиптических кривых и вы можете использовать любую из них. Вам необходимо менять алгоритм каждый час? Каждую минуту? После каждого зашифрованного сообщения? Не проблема. Вы можете строить многослойное шифрование наподобие RSA+ECIES. И все это всего в несколько строк кода.

    В-третьих: Совместимость. Несмотря на то, что многие современные языки имеют встроенную реализацию наиболее распространенных криптоалгоритмов, писать программы для Интернета Вещей, где данные могут считываться с датчиков и обрабатываться на Android и iOS устройствах, может оказаться весьма болезненным занятием. Virgil Security избавляет от подобных проблем. Мы предоставляем единый API, который будет работать на любой платформе.

    В-четвертых: К сожалению, наиболее уязвимым местом в любой системе по прежнему остаются пользователи. Не все пользователи умеют грамотно управлять ключами, более того, пользователи могут вообще не подозревать о наличии ключей. Virgil Security предоставляет возможность не только использовать глобальную инфраструктуру открытых ключей, но также создать свою собственную локальную инфраструктуру, доступную в рамках одного приложения. Разработчик может разрешить пользователям сохранять зашифрованные копии ключей в хранилище приватных ключей, что гарантирует восстанавливаемость данных в случае утраты ключа.

    Итак, как и говорилось выше, мы не пытаемся изменить мир. Мы предлагаем вам простой способ реализовать надежное шифрование и добавить его в ваш проект. Изменить мир и сделать его безопаснее способен каждый. Что для этого нужно сделать? Выбрать красную таблетку, разумеется.
    Virgil Security, Inc.
    0,00
    Мы превращаем программистов в криптографов.
    Поделиться публикацией

    Комментарии 46

      0
      Кто нибудь уже попробовал?
        +3
        вы можете добавить в свое приложение надежное End-to-end шифрование или беспарольную аутентификацию всего лишь несколькими строками кода.


        Хотелось бы подробнее, не «use case», как на сайте, а «success story».
        0
        Все же есть несколько вопросов. Интересно узнать принцип работы с токенами( не успел просмотреть полностью код ), реализовано через библиотеки xxPKCS11 или через APDU? Какие алгоритмы криптографические используются? Есть ли возможность к примеру выработать ключевую пару не только на токене но и в оперативки( временные ключи ). В целом идея конечно хорошая, сам долгое время занимаюсь решением данных вопросов( кроссплатформенная криптография ). Насколько мне известно на данный момент нет ничего действительно стоящего для работы с различными токенами на различных системах без привлечения инструментария разработчиков самих токенов( рутокен, etoken, jacarta и т.д. )
          0
          Добрый день alexeydevil, в качестве криптографической основы для доступа к сервисам Virgil Security, используется пара ассиметричных ключей. В данный момент мы не поддерживаем работу с токенами.
            0
            к сервисам Virgil Security

            Дак созданное приложение может работать в полностью закрытой от внешнего интернета сети?
            Условно говоря с ПК на ПК по 1 шлангу.


            И поддерживаю этот комментарий, хочется подробностей!

              +1
              Можно, если ПК1 содержит открытую часть ключа ПК2, и наоборот.
              Зачастую вся соль заключается в том, что нужно зашифровать данные для конечного пользователя зная один из его идентификаторов, например email.
                0

                Спасибо.

          0
          А в моём вайбере так и не появился обещанный замочек
            0
            А версия? с 6 обещали.
              0
              6.0.1

              А у вас появился?
                0
                Нет, у меня даже не обновился до сих пор.
                  0
                  Там, ещё одно условие, как писали. Надо заново на устройстве авторизоваться.
              0
              End-to-End шифрование через посредника? А смысл?
                0

                Смысл в том, чтобы избавить рядового разработчика от написания всей инфраструктуры для end-to-end encryption.

                  0
                  Virgil не является посредником, как таковым, шифрование происходит на стороне пользователя. У нас лишь хранятся открытые ключи.
                    +1
                    Т.е. Вы по сути PKI с удобным API и множеством binding-ов к языкам программирования. Понятно.
                      0

                      Да, так же опенсоурс Crypto библиотекой, которая позволяет выполнять основные криптографические операции как generate keys, encrypt, sign, verity, decrypt.

                        +1
                        В общем и целом да, но есть пара нюансов.
                        Во-первых, как вы правильно отметили мы поддерживаем множество языков программирования.
                        Во-вторых, в добавок к PKI мы предлагаем опенсорс библиотеку, реализующую большое количество современных криптоалгоритмов.
                        Наличие этих нюансов, хочется верить, избавляет нас от обидного ярлыка «посредник».:) Используя наш сервис разработчик способен реализовать именно end-to-end шифрование для своих пользователей. Генерация ключей происходит на устройстве пользователя. Публичный ключ перед загрузкой в хранилище заверяется разработчиком. Шифрование производится только с использованием аутентифицированного ВАШИМ приложением, а ни в коем случае не НАШИМ сервисом, ключа. Выполнение всех этих условий является обязательным и мы будем всячески напоминать об этом нашим разработчикам.
                    +3
                    Звучит вкусно. Но раз уж вы пишете на хабр, может, предоставите отдельную статью с примерами кода, гитхаб репы с n (n>1) минимальными проектами на разных языках и платформах, которые спокойно коммуницируют между собой, используя ваше API? Я вижу юз-кейс примеры в описании API, но это не полноценные приложения, а скорее просто proof of concept.
                      +1
                      Не спешите, мы пока еще только поздоровались.) Мы люди скромные и посчитали, что было бы невежливо кидаться с порога кусками кода.
                      В этом блоге мы планируем выкладывать и код и примеры и даже объяснения тех или иных решений. В общем подождите чуть-чуть, дальше, мы надеемся, будет интереснее.
                      +1

                      Данная статья является вводной. В ближайшем будущем мы планируем ряд статей с примерами по внедрению end-to-end encryption в различные сервисы, такие как Twilio. Сейчас на сайте в Quickstart, SDK, Crypto есть ссылки на публичные репозитории, где можно на рабочем примере увидеть работу наших сервисов.
                      Вот ссылка на GitHub, где можно найти все репозитории Virgil Security.

                        +1
                        Вот правильная ссылка, ваша ведёт на главную, https://github.com/VirgilSecurity
                        0
                        Здравствуйте, хотелось бы задать несколько вопросов:

                        1. Есть ли поддержка pgp?
                        2. У Вас java-android — на десктопе будет работать? (если зависимости на андроид апи)
                        3. Как управляется криптостойскость — есть ли аналоги «расширение до неограниченной юрисдикции» по аналогии в java.
                        4. Есть ли зависимости на java security, необходимо ли доставлять нативные dll или jar в дерево папок jvm (нестандартными методами в classpath).

                        Спасибо!
                          0
                          Здравствуйте, Snecachan,

                          1. Нет, pgp не поддерживается (мы используем ECIES).

                          2. Нет, не будет, поскольку в сборке под Android отсутствуют нативные библиотеки под десктопные платформы (Windows, Linux, Mac os). Для не-Андроид рекомендуется использовать Virgil Client.

                          4. Зависимостей на Java security нет, мы используем собственную библиотеку Crypto. Нативные библиотеки упакованы в JAR, так что нет необходимости что-либо доставлять.
                            0
                            3. Криптостойкость управляется непосредственно разработчиком конечного продукта, посредством выбора (ограничения выбора) ключей, которые генерируется в его приложении. Решения аналогичного в Java нет, поэтому ответственность за соблюдение криптографических ограничений, на данный момент, лежит полностью на разработчике.
                              0

                              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'
                            0
                            А что так наши алгоритмы однобоко представлены? Только один ГОСТ 28147-89, а Стрибог с Кузнечиком и подпись?
                              0
                              Будем добавлять ГОСТы по мере надобности. Пока что дефолтный — Curve25519.
                              0
                              Новые вопросы! ))

                              «Pricing» у вас есть, а где же «Terms&Conditions»? Хоть какие-нибудь гарантии задекларированы?

                                0
                                Вопросы более, чем приветствуются и мы рады вашему интересу.

                                Что касается Pricing, как видите, на данный момент все бесплатно и в открытом доступе наш код. Но у нас, безусловно, есть Terms of Service и Privacy Policy.
                                  0
                                  Спасибо! На главной не нашел этих ссылок.
                                +2
                                Начинание конечно хорошее, но я буду вынужден выступить с его достаточно жёсткой критикой.

                                1) «Вы когда-нибудь задумывались почему безопасность до сих пор остается такой серьезной проблемой?
                                Если кратко, то в основном по четырем причинам:»

                                Совсем не так. Хоть это и прозвучит как тавтология, но безопасность должна в первую очередь быть именно БЕЗОПАСНОЙ. Ни удобной, ни кроссплатформенной, ни какой либо ещё, а именно безопасной. Именно поэтому любые решения класса «простой в использовании чёрный ящик» порочны априори. Ведь в реальности никто толком не будет в него заглядывать. Ну и привет закладкам и т.п. Да, формально это открытый код и любой вроде может. Но реально то что? Много людей проверяют код той-же OpenSSL? На этой ноте перейду к следующему пункту.

                                2) «Более того, мы написали очень много кода»
                                В шифровании кода должно быть мало, очень мало. Нужно стремиться сделать только самый необходимый минимум возможностей, режимов и т.д. Ведь для того чтобы наша безопасность и правда стала безопасной этот код должен проверяться большинством тех, кто его использует. Чем этот код меньше, тем легче его проверять. По хорошему он ещё должен быть ОЧЕНЬ хорошо документирован. Вообще если взять основу из сцепки RSA, DHE и AES-CTR/GCM (сюда же хеши, скажем SHA256/512 и генератор случайных чисел), то донести принципы его работы до каждого разработчика должно быть не очень сложно. Просто объяснять нужно максимально доступно. Без понимания не будет никакой безопасности, а будет лишь видимость. Видимость же безопасности куда хуже чем её явное отсутствие.

                                3) «Вместо этого мы предоставляем гибкую инфраструктуру»

                                Чем сущность больше, тем выше вероятность ошибок и сложнее доказать их отсутствие.

                                4) «Мы реализовали большинство современных эллиптических кривых и вы можете использовать любую из них»
                                Использование элиптики это спорное решение. Порог понимания у элиптики куда выше, как следствие кол-во людей способных полноценно её понимать меньше. Моё глубокое ИМХО, что время для неё ещё не наступило. Но ещё раз повторюсь, это только моё личное мнение.

                                5) «Вам необходимо менять алгоритм каждый час? Каждую минуту?»

                                Зачем? Алгоритм или надёжный, тогда меняют только ключи, или нет, тогда зачем он нужен?

                                6) «К сожалению, наиболее уязвимым местом в любой системе по прежнему остаются пользователи.»

                                Именно поэтому единственный путь это их просвящение. Никакая серебряная пуля эту проблему не решит.

                                7) «использовать глобальную инфраструктуру открытых ключей»

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

                                P.S. И самый главный вопрос — вопрос доверия к вам. Не поймите меня не правильно, я лично против вас ничего не имею, но обоснованно не доверяю никому кто обещает мне решить мои проблемы, особенно в сфере безопасности, за просто так. Слишком велик соблазн…
                                  0
                                  Здравствуйте!
                                  Прежде всего позвольте поблагодарить за развернутый комментарий. Мы очень хорошо относимся к аргументированной критике и одной из причин нашего появления на Хабре было как раз таки желание выслашать как можно больше точек зрения.

                                  Совсем не так. Хоть это и прозвучит как тавтология, но безопасность должна в первую очередь быть именно БЕЗОПАСНОЙ. Ни удобной, ни кроссплатформенной, ни какой либо ещё, а именно безопасной.

                                  Вы совершенно правы. Безопасность не имеет пограничных состояний. Безопасность либо есть либо ее, простите, нет. Но скажите, разве удобство системы снижает вероятность ее безопасности? Мы уверены что одно не противоречит другому и стремимся достичь двух различных целей: безопасность наших решений и простота и удобство их использования. Обратите внимание, мы предлагаем вовсе не «черный ящик». Все наши протоколы и исходные коды совершенно открыты.
                                  Много людей проверяют код той-же OpenSSL?

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

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

                                  У криптографии на эллиптических кривых есть большое преимущество, связанное с размерами ключей и подписи. Для обеспечения приемлемого уровня стойкости в 128 бит вам потребуется 3072 битный RSA ключ или 256 битный ECDSA. Принимая во внимание закон Мура можно сказать, что использование RSA может оказаться в будущем слишком хлопотным делом.
                                  Зачем? Алгоритм или надёжный, тогда меняют только ключи, или нет, тогда зачем он нужен?

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

                                  И это абсолютно правильно! Мы сами никому не доверяем, поэтому и создали свой собственный сервис с блэкджеком и Curve25519:) Мы и не хотим, чтобы нам доверяли. Вы вполне можете использовать наш PKI, но при никогда не предавать нам своих приватных ключей. Более того, при этом вы можете даже подписывать ключи своей собственной реализацией RSA и отвергать все ключи лишенные вашей подписи.
                                  0
                                  Не увидел в списке поддерживаемых языков любимого всеми студентами Delphi, вы про него не забыли или забили?
                                    0

                                    ))) Ну тут спорный вопрос, нынче студенты модные стали им JS, C#, Python подавай. Ну а если серьезно то пока Delphi мы не планировали поддерживать.

                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      +2
                                      Куда вам столько кривых? Я бы наоборот выкинул всё, кроме 25519, потому что только она соответствует критериям безопасности, дуракоустойчивости (любой массив в 32 байта является валидным ключом) и скорости. Это самая быстрая из всех безопасных кривых, к тому же не профинансирована государством.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          Не понял вашего комментария про 128 бит. Это мало, вы считаете?
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              +1
                                              Если лет на 5-10, то пора во всю внедрять post-quantum crypto, тем более, что его уже во всю разрабатывают
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                  +1
                                                  Не соглашусь. Там ежегодные конференции проводятся, это одна из самых горячих тем в последние годы. Даже уже выпустили рекомендации по используемым алгоритмам и параметрам

                                                  McEliece, например, создан в 1978 году и до сих пор ничего на него не накопали. Там просто ключи везде большие, поэтому алгоритмы непопулярны в широких кругах

                                                  Но то, что для симметричных алгоритмов рекомендуют 256 бит это да, правда тоже «на всякий случай». Прям утверждений, что после появления квантовых компов безопасность симметричных алгоритмов драматично упадет, нет
                                        +1
                                        А NIST SP 800-90A у вас с дыркой?

                                        Данный алгоритм реализован как часть библиотеки MbedTLS — https://tls.mbed.org/ctr-drbg-source-code
                                        На дынный момент уязвимостей в данном модуле не найдено — https://tls.mbed.org/security

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое