Чорний піар Telegram. Кому вірити?

imageНещодавно на Geektimes підняли шум зі статтею «Поганий Telegram» або Як я не взяв грошей за чорний піар Telegram на Хабрахабре. В результаті з'ясували, що знайомий Бурумыча читає листування дочки і що привітання «Добрий день» краще ніж «Доброго часу доби».

Щоб вкинути у вентилятор корисної інформації, ми з фахівцями компанії Edison зробили добірку публікацій про Telegam і безпечні месенджери, щоб допитливий читач міг самостійно зробити висновок (а не отримати «проплачену» експертизу) чому варто довіряти і чим користуватися для своїх цілей. Про рівень довіри/жовтизни ЗМІ пропоную читачеві вирішити самостійно.

Потік адекватною і неадекватною інформацією про безпечність комунікації (і месенджерів в тому числі) росте і буде рости, і дуже хочеться, щоб на Хабре можна було знайти грамотну, незалежну і зрозумілу аналітику.

Якими критеріями користуватися для оцінки безпеки месенджерів, можна підглянути у борців за цифрову недоторканність — Electronic Frontier Foundation (EFF). До речі, питання, чи є ці критерії не є вичерпними або потрібні додаткові (наприклад, про маскування метаданих)?

Щоб підвищити градус об'єктивності і незалежності, прошу висловитися в коментах тих, хто розбирається в питанні щодо безпеки месенджерів.

На основі яких даних можна робити висновки?


«Інформаційна робота стратегічної розвідки» Вашингтон Плетт

Electronic Frontier Foundation
www.eff.org/secure-messaging-scorecard

Організація Electronic Frontier Foundation (EFF) опублікувала серйозний аналітичний матеріал (останнє оновлення 2015-11-03), оцінивши ступінь безпеки та приватності мобільних і онлайн-месенджерів. EFF присуджувала учасникам бали, оцінюючи програми за сімома параметрами.

  1. Шифрує дані при передачі?
  2. Захищені дані від читання сервіс-провайдерами?
  3. Може користувач упевнитися в автентичності особистості свого співрозмовника?
  4. Захищена історія листування від розшифровки при перехопленні поточного ключа (у цьому питанні мається на увазі, що ключ шифрування повинен постійно змінюватися, а використані ключі безпечно видалятися разом з тими випадковими даними, на основі яких вони були побудовані)?
  5. Відкритий програмний код рішення?
  6. Описані чи детально використовувані методи шифрування?
  7. Проводився за останні 12 місяців незалежний аудит безпеки?
Детальніше про критерії англійською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 all along 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 at the stored endpoints (i.e. by users, not by servers). The keys should never leave endpoints except with explicit user action, such as a key to backup 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 are possible solutions, but any solution verify must 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 provide the app 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 to this setup 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 that require 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, tends to this 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. There Has 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. Визнаючи проектів житлового 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.
[джерело]


Топ-лист найбільш захищених месенджерів на думку EFF:

  • Chatsecure — це безкоштовне iOS — і Android-додаток для обміну повідомленнями на базі відкритого коду з підтримкою шифрування. Розробником є Guardian Project. Месенджер відповідає всім необхідним параметрам, запропонованим EFF, гарантуючи найвищу ступінь безпеки і приватності (однак лише за умови використання разом з Tor-плагіном Orbot на базі Tor).
  • CryptoCat — відкритий месенджер з підтримкою шифрування, працює з браузерами Chrome, Firefox, Safari і Opera, а також в якості окремого сервісу в Apple OS X і iPhone. Цього літа розробники CryptoCat займалися пошуком спонсорів для розробки Android-версії і створення шифрованого відеочату — можливо, скоро «криптокот» з'явиться і на цій платформі.
  • Signal, RedPhone і Textsecure — продукти компанії Whisper Systems, призначені, відповідно, для обміну повідомленнями на iOS-пристроях, здійснення конфіденційних дзвінків з Android-пристроїв і листування між Android-користувачами. Кожен із додатків має відкритий вихідний код і пропонує повне шифрування передачі та зберігання даних.
  • Silent Phone і Silent Text — сервіси безпечних дзвінків та обміну повідомленнями від Silent Circle. Вони, звичайно, платні, зате сумісні з платформами iOS і Android, а також працюють на традиційних ПК. Компанія Silent Circle також розробила власну модель захищеного від проникнення смартфона на базі модифікованої версії Android під назвою Blackphone. Також пропонується підтримка корпоративних клієнтів.
  • Telegram — безкоштовний багатоплатформовий месенджер, що дозволяє обмінюватися повідомленнями і медіафайлами. У системі використовується проприетарная серверна частина, що працює на потужностях декількох хостинг-компаній США та Німеччини, і кілька клієнтів з відкритим вихідним кодом (під GNU GPL). Для месенджера був створений протокол MTProto, що передбачає використання декількох протоколів шифрування. При авторизації та аутентифікації використовуються алгоритми RSA-2048, DH-2048 для шифрування при передачі повідомлень протоколу в мережу вони шифрування AES з ключем, відомим клієнта і сервера. Також застосовуються криптографічні хеш-суми SHA-1 і MD5.
  • Pidgin — багатопротокольний опенсорсовый IM-клієнт з підтримкою Jabber, AIM, ICQ, GTalk, MSN, Yahoo!, Sametime та ін. Є можливість аудіо та відео зв'язку.


Обережно довга картинка
Зведена таблиця



Журнал ][акер


Хабр


Касперський


Security Lab


TJ


Roem.ru




РБК
Чиновники вирішили обмежити спілкування росіян в месенджерах (9 грудня 2015)
Автори (законопроекту про обмеження) пропонують внести в закони «Про інформацію» та «Про зв'язок» таке поняття, як «інформаційно-комунікаційні сервіси». Під їх діяльністю мається на увазі передача текстових, голосових і графічних повідомлень, технологічно нерозривно пов'язаних з послугами зв'язку, що надаються третіми особами на мережах передачі даних операторів зв'язку». Представники інтернет-компаній і операторів, ознайомившись з документом, прийшли до висновку, що перш за все йдеться про месенджерах, хоча теоретично під дію закону можуть потрапити і соцмережі.


p.s.
Згідно исследованию, проведеного «Лабораторією Касперського» спільно з B2B International, 62% опитаних не вважають онлайн-месенджери безпечними, 61% не довіряють IP-телефонії, 60% насторожено ставляться до видеочатам. І тим не менше 37% взяли участь в опитуванні найчастіше використовують для спілкування саме онлайн-месенджери, 25% — месенджери з соціальних мереж і 15% — VoIP-сервіси.

Основні висновки дослідження


Одна з критичних вразливостей сучасних месенджерів (в тому числі і Telegram) — це незахищені метадані (зловмисники можуть отримати список контактів для визначення кола спілкування, час доступу в мережу і тд), а дуже часто факт комунікації набагато важливіше змісту комунікації. Якими інструментами це вирішити (виключити з системи централізовані серваки або щось ще) пропоную обговорити в коментах.


UPD

ru_crypt:
останні результати аналізу протоколу MTProto: eprint.iacr.org/2015/1177.pdf. У цій роботі показано, що даний протокол не є стійким у моделі IND-CCA, тобто можливо будь шифртекст перетворити в деякий інший шифртекст, який може бути розшифрований у вихідний відкритий текст. Незважаючи на те, що атака теоретична, автори рекомендують все-таки не використовувати самопальні рішення, а реалізовувати добре перевірені конструкції, ну і пропонують змінити протокол, щоб атака не проходила.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.