Eto
Вероятнее всего, вы уже осведомлены о препятствующих сохранению анонимности свойствах проприетарных мессенджеров (таких как Viber, WhatsApp, Skype и прочее), в которых отсутствует криптографический набор, зато они изобилуют множеством потенциальных лазеек для перехвата личной информации. Поэтому я хотел бы рассказать о слабых местах в схеме общения между вами и собеседником при использовании открытых и этичных месседжеров.
Во-первых, чем древнее версия Android, тем она имеет больше неприятных черт со стороны безопасности, однако начиная с 6 все стало как-то повеселее в плане разрешений, доступа и разграничения прав. О каких слабостях необходимо помнить каждому, осуществляющему конфиденциальную переписку по зашифрованным каналам.
1. Не шифрованный буфер обмена.
Т.е если вы копируете сообщение себе на смартфон или другому контакту в меседжере, то стоит иметь в виду, что на девайсе может быть множество приложений, которым доступен ваш буфер обмена. В этом плане хороша прошивка CopperheadOS, которая позволяет ограничивать доступ к буферу обмена, чтобы информация не считывалась другими приложениями (запрет возможен лишь для фоновых приложений).
2. Выскакивающие push-уведомления.
Если они сторонних производителей, к примеру, Google или от производителя смартфона, то с помощью данного инструмента может быть доступна по крайней мере часть информации сообщения.
3. Клавиатура.
Важно помнить, что сама клавиатура на любом смартфоне это отдельное приложение, которое может запоминать каждую нажатую букву и отсылать куда не стоило бы. Если у вас Android - посмотрите в разрешениях клавиатуру, а также какие действия вы ей позволили. А если вы имеете iPhone, тогда компания Apple не даст вам посмотреть исходный код ни целиком вашей ОС, ни отдельно клавиатуры, и вы можете хоть обшифроваться с ног до головы PGP, GPG, OTP, TLS, AES и прочими криптографическими инструментами.
Важным шагом по безопасности будет тот, когда каждому желающему будет позволено блокировать отдельно и абсолютно каждую функцию приложения, а не выбранную. Когда буфер обмена будет четко и прозрачно регулируем в доступе, а также шифрован, чтобы каждый раз приложение должно было бы получать позволение на его чтение, т.е важно постараться максимально приблизить возможности настройки девайса к вы полнению этих принципов и выбирать для себя инструменты установки более гибких, но строгих персональных правил доступа. также у пользователя возникают вопросы, почему отключать микрофон можно только в некоторых приложениях, и то, в последних версиях. следующий способ чтения мессенджеров, так скажем, аналоговый, и несмотря на кажущуюся абсурдность, его исключать не стоит - это прямое подглядывание из-за плеча.
Я бы хотел привести обобщенные результаты исследования, которое было призвано зафиксировать текущее состояние на момент его проведения. Это примерный перевод использовавшейся мотивировки анализа:
"В течение многих лет ради обеспечения нашей с вами анонимности и безопасности привлекались отличные специалисты, чья деятельность в этом направлении позволила бы популяризировать методы надежного шифрования и принципы open source. Откровения Сноудена подтвердили наши худшие опасения: правительства действительно собирают наши личные данные для собственной выгоды. Взаимодействуя с корпорациями, поставляющими услуг, они так или иначе предают персональную информацию огласке.
Даже зная о тотальной слежке почему люди так и не обеспечивают с должной тщательностью защищенность обмена той или иной (любой!) информацией использованием методов шифрования? Разве это не позволило бы нам общаться куда более свободно, без этого повсеместного надзора?
А причина очень проста: либо безопасность, либо удобство использования. Большинство средств, понятных для неискушенного пользователя, не способны обеспечить / не имеют в своей основе эффективные методы, как end-to-end шифрование и открытый исходный код. И в то же время, действительно надежные инструменты мессенджеров часто непросты в использовании; сложности могут возникнуть при установке ПО, подтверждении входа в систему, создании аккаунта, или пользователь сам раскрыл личные данные по неосторожности.
Наряду с менее крупными компаниями, специализирующимися на
We chose technologies that have a large user base--and thus a great deal of sensitive user communications--in addition to smaller companies that are pioneering advanced security practices. We’re hoping our scorecard will serve as a race-to-the-top, spurring innovation around strong crypto for digital communications.
Methodology
Here are the criteria we looked at in assessing the security of various communication tools.
1. Is your communication encrypted in transit?
This criterion requires that all user communications are encrypted along all the links in the communication path. Note that we are not requiring encryption of data that is transmitted on a company network, though that is ideal. We do not require that metadata (such as user names or addresses) is encrypted.
2. Is your communication encrypted with a key the provider doesn't have access to?
This criterion requires that all user communications are end-to-end encrypted. This means the keys necessary to decrypt messages must be generated and stored at the endpoints (i.e. by users, not by servers). The keys should never leave endpoints except with explicit user action, such as to backup a key or synchronize keys between two devices. It is fine if users' public keys are exchanged using a centralized server.
3. Can you independently verify your correspondent's identity?
This criterion requires that a built-in method exists for users to verify the identity of correspondents they are speaking with and the integrity of the channel, even if the service provider or other third parties are compromised. Two acceptable solutions are:
- An interface for users to view the fingerprint (hash) of their correspondent's public keys as well as their own, which users can verify manually or out-of-band.
- A key exchange protocol with a short-authentication-string comparison, such as the Socialist Millionaire's protocol.
Other solutions are possible, but any solution must verify a binding between users and the cryptographic channel which has been set up. For the scorecard, we are simply requiring that a mechanism is implemented and not evaluating the usability and security of that mechanism.
4. Are past communications secure if your keys are stolen?
This criterion requires that the app provide forward secrecy, that is, all communications must be encrypted with ephemeral keys which are routinely deleted (along with the random values used to derive them). It is imperative that these keys cannot be reconstructed after the fact by anybody even given access to both parties' long-term private keys, ensuring that if users choose to delete their local copies of correspondence, they are permanently deleted. Note that this criterion requires criterion 2, end-to-end encryption.
Абсолютно точно то, что эти ключи невозможно восстановить после удаления истории сообщений, даже если третья сторона получит их: когда пользователи удаляют обе копии своего чата
Подразумевает также, что защищенные данные после удаления не могут быть восстановлены, т.к и ключи, использовавшиеся, например, для самоуничтожения, также незащиту
Note: For this phase of the campaign, we accept a hybrid forward-secrecy approach with forward secrecy on the transport layer (for example through TLS with a Diffie-Hellman cipher suite) and non-forward-secret end-to-end encryption, plus an explicit guarantee that ciphertexts are not logged by the provider. This is a compromise as it requires trusting the provider not to log ciphertexts, but we prefer this setup to having no forward secrecy at all.
5. Is the code open to independent review?
Доступность кода для просмотра пользователем
.. код был опубликован, и его структура может независимо дополняться. Пусть даже код выпущен без лицензии свободного/открытого ПО, хотя это, конечно, желательно, но главное, чтобы код, влияющий на работу средства связи, и используемое пользователем шифрование были доступны для поиска багов, бэкдоров и других внутренних ошибок.
This criterion requires that sufficient source-code has been published that a compatible implementation can be independently compiled. Although it is preferable, we do not require the code to be released under any specific free/open source license. We only require that all code which could affect the communication and encryption performed by the client is available for review in order to detect bugs, back doors, and structural problems. Note: when tools are provided by an operating system vendor, we only require code for the tool and not the entire OS. This is a compromise, but the task of securing OSes and updates to OSes is beyond the scope of this project. Примечание: если инструменты предоставлялись системно, то проверялся код инструментов шифрования, а не всей ОС. Это создаёт видимость менее детального изучения, однако суть исследования обусловлена именно работой мессенджеров.
6. Is the crypto design well-documented?
Ясное и детальное описание технических возможностей используемых в приложении криптографических инструментов. Предпочтительнее в текстовой форме для изучения профессиональными криптографии. Это позволит получить ответы на следующие вопросы:
This criterion requires clear and detailed explanations of the cryptography used by the application. Preferably this should take the form of a white-paper written for review by an audience of professional cryptographers. This must provide answers to the following questions:
- Which algorithms and parameters (such as key sizes or elliptic curve groups) are used in every step of the encryption and authentication process какие алгоритмы (размер ключа, эллиптическая последовательность и т.п) используются на каждом этапе шифрования и авторизации
- How keys are generated, stored, and exchanged between users как ключи производится генерирование, хранение и обмен между пользователями
- The life-cycle of keys and the process for users to change or revoke their key
- A clear statement of the properties and protections the software aims to provide (implicitly, this tends to also provide a threat model, though it's good to have an explicit threat model too). This should also include a clear statement of scenarios in which the protocol is not secure.
7. Has there been an independent security audit?
This criterion requires an independent security review has been performed within the 12 months prior to evaluation. This review must cover both the design and the implementation of the app and must be performed by a named auditing party that is independent of the tool's main development team. Audits by an independent security team within a large organization are sufficient. Recognizing that unpublished audits can be valuable, we do not require that the results of the audit have been made public, only that a named party is willing to verify that the audit took place.
We've discussed this criterion in depth in a Deeplinks post: What Makes a Good Security Audit?