Комментарии 57
наводит на подозрение, что разработчикам как будто кто-то мешает
Всё проще: фича почти не востребована пользователями, поэтому и тратить время разработчики предпочитают на что-то такое, чем пользователи хотят и будут пользоваться.
Например, в нашем продукте сейчас точно такая же ситуация применительно к шифрованию в XMPP: либо оно принудительно включено, либо принудительно отключено. Сами мы им не пользуемся, отчего оно уже много лет пребывает в состоянии "экспериментальная возможность". Пользователи тоже не просят. Раз это никому не интересно, то оно так и будет жить в экспериментальном и неудобном виде.
Пользователями в массе своей и HTTPS был не востребован (более того, они как раньше не знали, что это такое, так и сейчас не знают), однако согласованные усилия разработчиков браузеров привели к тому, что HTTP без S практически вымер.
Но то браузеры, которых, несмотря на все браузерные войны, общераспространённых всегда только несколько штук было. А с почтой нужно, чтобы и почтовые сервисы, и почтовые клиенты проталкивали шифрование, пока не наберётся критическая масса пользователей оного. Если бы какой-нибудь Gmail с начала запуска по умолчанию создавал и публиковал сертификаты - может, к текущему моменту и взлетело бы.
В случае HTTPS всё просто и прозрачно для пользователя, ему не нужно делать никаких телодвижений - браузеры проверяют сертификаты, а сами сертификаты это головная боль владельцев сайтов.
В случае же с почтой всё совсем не так - во-первых, сертификаты (или ключи в случае PGP) нужны самим пользователям, их нужно где-то брать и что-то за это платить, а если не платить (PGP & co) то придётся заморачиваться цепочками доверия, как-то проверять подлинность и вот это всё - это не очень приятно и времязатратно даже для понимающих людей, что уж говорить про условных сантехников и флористов.
Шифрование почты станет мейнстримом только если (и это большое "если") кто-то придумает систему аналогичную HTTPS когда у пользователя реально будет "один клик" для отправки зашифрованного письма и проверки подлинности полученных, без возни с приватными ключами и прочим, и при этом не придётся всё это повторять при смене адреса email, причём не только своего но и всех с кем идёт переписка.
Так я и пишу, что кто-то из больших игроков должен был сделать удобно и по умолчанию. Условно говоря, после регистрации в Gmail сразу сообщать - "мы создали вам ключевую пару, приватный ключ сохранён в Гугл-аккаунте, публичный опубликован в Гугл-каталоге, пользуйтесь" (само собой, не такими словами, а понятными для пользователя). Для продвинутых ссылочка "advanced options", где что-то можно поменять. А потом автоматически подсказывать, что у получателя тоже есть сертификат и не хотите ли зашифровать. Или "судя по тексту письма, в нём чувствительные данные, не хотите ли сначала предложить получателю бесплатно и одним кликом завести свой сертификат". Ну и т.п. И при этом обеспечить совместимость и совместную работу своих стандартов с другими, кто захочет подтянуться.
Тут скорее другой вопрос, что приватные ключи можно хранить либо удобно, либо безопасно. Если он будет храниться на стороне почтового сервиса - то это не сильно добавит безопасности в чём бы то ни было. А если на стороне клиента - то да, нужны нетривиальные телодвижения, которых обычный пользователь никогда совершать не будет...
А для чего это нужно большим игрокам? Например google и microsoft?
Они уже давно (как минимум года 3 назад) реализовали возможность отправлять письма в режиме конфеденциальности. Это даёт даже больше возможностей пользователю чем подпись с помощью шифрования, в частности:
возможность ограничить, сколько письмо будет доступно (например через 3 дня письмо невозможно будет открыть
возможность заблокировать скачивание, печать(относительно) и тп письма.
Видел так же системы где можно даже отозвать письмо, после его отправки.
Во всех случаях, фактически письмо даже не уходит с серверов отправителя, то есть, "перехватить" содержание намного сложнее.
Так же есть DKIM ключи, которые подписывают что да, это ваш сервер отправил это письмо, а не сторонее лицо.
Ещё один важный вопрос стоит учесть: Как много людей пользуются только 1 почтовым клиентом? Очень многие пользуются тем же Outlook на компьютере, на телефоне и иногда заходят через веб. Как сделать чтобы подпись работала на всех устройствах (где будем шифровать, на клиенте или на сервере? ) И чтобы каждый из клиентов знал у кого из получателей есть возможность читать зашифрованную почту? Опять получается что это всё происходит на стороне сервера, и о какой безопасности мы говорим? Как минимум почтовый сервис может читать все ваши письма.
И да, судя по всему в Outlook есть эта функция, но она скорее всего мало кому интересна.
Для чего это нужно Гуглу и Майкрософту - я не знаю. Наверное, ни для чего, и в этом вся причина. Хотя забота о privacy и конфиденциальности неплохо продаётся.
"Режим конфиденциальности" Gmail - это вообще не про почту, в самом письме нет "защищённого" содержимого. С таким же успехом можно отправлять ссылки на зашифрованные файлы или эти же файлы во вложениях... или вообще общаться в мессенджерах с end-to-end шифрованием. Последний вариант в основном и выбирают, забивая на почту вообще.
DKIM - это про другую историю, он содержимое письма никак не защищает. Шифрование почты зачем нужно? Чтобы если товарищ майор с ордером (или без оного, но с убедительными аргументами) придёт к хостеру почтового сервиса и либо изымет сервер, либо убедит того самогó скопировать ящик нужного пользователя, - означенный товарищ текста сообщений всё равно не увидел бы. Ну или чтобы того же не сделал ваш собственный сисадмин, "мотивированный" вашими недоброжелателями. При хранении ключа на стороне сервера эта задача решается только частично, да - если получили доступ к Вашему серверу, прочитают Ваши входящие, но не Ваши исходящие. Слабое утешение в большинстве случаев. Поэтому я и пишу, что хранение приватных ключей - главная архитектурная проблема во всей этой истории. Можно или безопасно, или удобно, но не одновременно.
В Outlook шифрование есть, я его даже использовал в своё время. Но это ещё более недружественная пользователю система, чем PGP (с плагином под Outlook или Thunderbird). Там вообще сложно без бутылки понять, откуда тот сертификат должен взяться... В корпоративной среде, где всё преднастроено и зашито в групповые политики, оно, может, и взлетит, но в общем случае крайне неудобно.
проблема в том что вот такая вот "шифрованая" почта создаёт иллюзию безопасности.
что мешает google передать приватные ключи кому угодно?
То, что гуглу на Вас с Вашими ключами наплевать. Особенно, кстати, после того, как российская дочка у них закрылась и последние стимулы хоть как-то реагировать на формальные или неформальные просьбы российских властей очевидно исчезли. Бояться надо на АНБ с Гуглом и Метой, а коррумпированного оперативника из родного УВД, к которому ваш конкурент / оппонент придёт. Если, у Вас, конечно не стратегический / международный бизнес, но тогда Вы сами и так прекрасно знаете, чего Вам бояться и как защищаться. А остальным достаточно руководствоваться простым правилом - никакие чувствительные данные не хранить в той стране, в которой ведёшь бизнес.
Это вы сейчас рассуждаете как физлицо-индеец Джо, в данном случае можно письма вообще в открытом виде слать, они реально не нужны никому
А вот если вы какаянить огромная международная корпорация и у вас есть конкурент похожих размеров… то тут можно начинать бояться например инсайдеров в гугле направленных против вас
Это может звучит диковато, но это огромный теневой сектор и он существует, утечки не только у яндекса с мейлом в РФ происходят и тренинги с аудитами безопасности в крупных компаниях не просто так. например нужно алертится даже если коллега просит тебя переслать тебе документ который вроде как ему по его должности не нужен (я например всегда уточняю у руководства правомерность таких запросов, как раз после опыта работы в крупной забугорной корпорации из финсектора)
основывать свою безопасность на факторе "из РФ эта компания ушла — значит мне ничего плохого сделать не может" — крайне наивно
Я не сомневаюсь, что международные корпорации с построением своей безопасности справятся без чтения комментов на Хабре :) А вот российских бизнесов, которые и друг на друга уголовки заводят, и в судах в корпоративных конфликтах бьются, и сами же услугами пробива не брезгуют, - и при этом держат почту на Яндексе/Мейле, я вижу предостаточно.
я думаю тут наверняка были люди которые помнят что openrelay когда то был СТАНДАРТОМ. все удивлялись - КАК это нельзя передать письмо через любую почтовую систему?!
однако пара важных узлов запретила open relay и теперь в общем в голову никому не придёт его открывать.
короче кто-то должен начать.
ведь тайна почтовой переписки защищена Конституцией и является одним из основных прав человека.
вроде уже в прошлом или позапрошлом году в РФ решили, что почтовая переписка = бумажная переписка, а то что вы там байтики шлете — это не почта
ну это лирика, а вообще как я понял все заткнулось на сложности реализации. я по долгу работы много общался через зашифрованную почту и… и это геморрой, адресату надо както отправить открытый ключ, надо получить ключ от него, надо настроить адекватно клиента, гдето хранить ключи, чтото делать если ключ потерялся, в моем случае ключи вообще хранились в usb токене а потом еще на срвере надо было обрабатывать такие письма и там както правильно хранить эти ключи и обновлять их… а люди не способны какимто одним способом это делать… то в аське то через личную почту… разве что голубями их не присылали
а потом с определенной версии OpenPGP её перестали в РФ поставлять и переход на OpenGPG дался крайне болезнено из-за некой… скажем так кривизны плагинов для оутлука с волшебными кнопочками
вобщем история мне конечно эта вся очень нравилась, но поскольку я учавтсвовал в настройке этого всего и траблшутинге проблем в стиле "я не могу письмо от вас прочитать почемуто, вчера мне компьютер поменяли… как надо было открытый ключ по новой отправить?" (а в переписке 15 адресатов половина которых их больших компаний за бугром которые работают по ночам для нашего пояса… и трое суток все друг другу ключи шлют вместо работы… когда вы уговорите Сьюзи из Атланты что у вас ключ поменялся… она его поменяла и ушла в отпуск… а вы уже тоже самое начинаете Мери объяснять… при этом вы не админ, а менеджер
а потом ктото забыл кнопку шифрования тыркнуть и последние 4 письма в открытом виде ходят… ББезопасность
вот кмк по этому оно и не взлетело
Ну отправка открытых ключей индивидуально каждому получателю - это уж какой-то совсем извращённый способ. Есть же key server'ы, на которых они публикуются/отзываются, и есть протокол WKD для выдачи ключей для определённого домена. Что позволяет отправителю, если всё это настроено, просто по адресу почты при отправке письма автоматически подтянуть актуальный в данный момент публичный ключ получателя.
А вот кривость софта, отсутствие единых стандартов - да, проблема. Хранение приватного ключа так, чтобы его применять и в десктопном клиенте, и в мобильном, и в веб-интерфейсе, и при этом это было удобно и понятно самому тупому пользователю (а иначе не взлетит), - проблема в квадрате.
Есть же key server'ы, на которых они публикуются/отзываются
отличная точка атаки, да, ломанул такой сервер через который банки общаются и такой митм можно устроить, закачаешься
делать его внутрикорпоративным = поиметь проблем с интеграцией с теми кто с вами переписывается потому что полюбому оно будет не совместимо со всем сразу
=====
ну это конечно все рассуждение на тему "А вот кривость софта, отсутствие единых стандартов — да, проблема."
так что все верно
Ну для того же HTTPS риском "а вот ломанул такой сервер доверенного корневого центра и устроил MITM-атаки вообще всем" как-то управляют :) Не вижу причин, почему бы так же и тут не могло получиться. Так что да, единые стандарты... ладно эти серверы, так ведь даже на уровне формата. Более или менее всё работает с OpenPGP. Но MS в Outlook при этом запилила свой велосипед с S/MIME. Google не пилил ничего, но если бы взялся - тоже 100% это был бы не PGP, а нечто своеобычное.
key server это шит. это убивает саму идею того что ключ - это идентификатор пользователя. и не имея гарантии что это именно тот ключ именно того пользователя вы не можете утверждать что послали письмо тому кому хотели.
вся концепция "web of trust" держится только на знакомствах. то есть первоначально вы должны каким-то способом "привязать" ключ к человеку.
Так оно не взлетит никогда. Пользователи не будут совершать лишних телодвижений. Даже в варианте Autocrypt, где ключ передаётся в заголовке незашифрованного сообщения. Целевая схема - чтобы 100% сообщений по умолчанию были сразу зашифрованы и пользователь для этого не предпринимал никаких усилий. А она без того или иного механизма централизованного хранения публичных ключей не взлетит. Чтобы снизить риски - такое хранение, IMHO, может осуществляться либо на ограниченном количестве всячески аудируемых доверенных серверов, которым будут верить почтовые клиенты / сервисы, а при любом инциденте - доверие будет утеряно (по модели корневых центров сертификации). Либо - на сервере получателя, и тогда тот сам несёт риски. А вот с приватными ключами гораздо сложнее...
может осуществляться либо на ограниченном количестве всячески аудируемых доверенных серверов
общедоступная спам-база угу
Чем с т.зр. удобства формирования спам-баз возможность постучаться на key server и спросить "есть ли ключ для адреса foo@bar.com?" отличается от возможности постучаться на mail.bar.com и спросить "хочу отправить почту пользователю foo, есть такой?"
mail.bar.com и спросить "хочу отправить почту пользователю foo, есть такой?"
тем что туда стучатся сервера которые в банлисты спамеров попадают
а на ключевые сервера почты будут ходить все подряд со своих компов, в штатном режиме (не у всех же домен будет с централизованным обменом ключей… прям dns получается)
Я, честно говоря, в методологии сбора спам-баз полный чайник :) А что, сейчас их не собирают через ботнеты, которые именно что с нигде не засвеченных пользовательских адресов делают "telnet mail.bar.com 25; HELO imnotspammer.fake.com; MAIL FROM:foo@fake.com, RCPT TO:ivanov@bar.com" и записывают результат?.. Вроде ж все проверки на обратную запись, наличие в DNSBL и т.п. обычно после этого происходят, уже в ответ на DATA...
Да и вообще, ещё есть смысл их таким способом собирать именно для спама (а не для целевой фишинговой атаки на определённую контору, скажем), если можно бесплатно или за скромные деньги купить набор утечек с миллионами живых адресов?..
я могу лишь повторить - все "автомагические" штуки не дают доверия. обязательно кто-то должен проверить.
когда pgp делали сеть была относительно маленькая и идея состояла в том что все друг с другом знакомы. если бы подключить pgp к соц-сетям. вот тогда такой ключстор мог бы иметь смысл.
что-то такое сделано в рамках keybase.io
Пишет системный администратор служебную записку, мол, так и так, вот, я сделал, смотрите, оно всё само:
Тут вот у нас сервер ключей, все, как в удостоверяющих центрах, аппаратные хранилища неизвлекаемых ключей
Тут вот плагины под все возможные почтовые клиенты, даже веб
Тут вот домен, политики, ключи приватные сами создаются, пользователь лично придумывает пароль, привязывает 2FA на личном телефоне или аппаратный генератор, ключи пишутся на сервер ключей
Тут вот для внешних контрагентов интерфейс, оно даже всё само подхватывает их MTA и по самому последнему стандарту с ними договаривается о ключах и способах эмбеддинга писем, с переконвертацией полей в письме, если MTA получателя сообщает, что у них по-другому принято
...
В общем, дайте премию. Директор, конечно, отписывает безопасникам, мол, видите, как теперь всё безопасно, а вы, бестолочи, за три года вдесятером не смогли.
А те ему и отвечают: а вот, допустим, менеджер Иванов захотел продать бесценных коммерческих тайн на сторону. И исполнил свою часть сделки с конкурентами по электронной почте. А там всё само и зашифровалось, а где не само, подсказало, как сделать первый раз, чтоб дальше уж точно само. И вот там долгая и длинная цепочка электронной переписки, которую мы даже промаркировать не можем. Понятно, что мы уже в заднице, но даже при полной уверенности, что это дело рук Иванова, нам его хотя бы к ответственности, например, уголовной, как привлечь? Да ладно привлечь, уволить хотя бы как законно? Нам вот этот, купленный всего лишь в прошлом году, DLP куда лучше отдать: в столовую, чтоб ложки сушились, или лучше в упаковочный цех, чтоб упаковщики примерно половину палеты не на глаз меряли, а уже удобнее по подходящему типоразмеру прикладывали?
Это там, где ещё более-менее бардак в процессах. А там, где процессы выставлены, системный администратор получит реджект ещё на этапе обсуждения идеи и до всяких r&d.
Ну вот это как раз решается тем, что приватный ключ менеджера Иванова согласно групповым политикам домена хранится централизованно. Но отдельно от почтового севера, само собой, где-нибудь подальше. А директору рассказывают другую историю - что если почтовый сервер завтра изымут в рамках "маски-шоу", заказанного конкурентом, то прочитать смогут примерно ничего. И это куда больший риск, чем ущерб от сколь угодно коварного менеджера.
Если маски шоу изымают почтовый сервер, они изымают и централизованный сервер с приватными ключами. А, поскольку там всё хранится так, что софт имеет доступ к содержимому без воли владельца ключа, то конкурентные маски шоу все нужные им данные отлично прочитают.
Ну разносить сервера по локациям тоже надо. И шифровать диски, и бекапы, и много чего ещё. В общем, моделируем все угрозы, все риски и пытаемся закрыть максимальное количество сочетаний первых с вторыми. Понятно, что многое и без шифрования писем решается, а многое и с ним не решить - но дополнительный инструмент был бы для этой задачи не лишним.
Как минимум, шифрование почты уникально в том, что позволяет быть чуть спокойнее, если тем или иным способом получат доступ не к вашему серверу (предположим, вы его и так защитили от всех угроз), а к серверу вашего контрагента, с которого вам отправляли конфиденциальные письма (и вот за него вы уже не можете быть так спокойны).
Вместе с сервером контрагента изъяли и компьютеры из офиса контрагента. А на них те самые ключи. Ключи, возможно, даже запаролены, а пароли знают только конкретные пользователи. Вот только беда: пользователь компьютера наделяется статусом свидетеля, а свидетель, в отличие от обвиняемого или подозреваемого, не наделён правом отказа от предоставления свидетельств. И это не только в РФ так, если что.
Итак, какую проблему решает эта техническая связка? Я подчеркну: решает.
У контрагента публичные ключи от ваших ящиков. Которые даже изымать не надо, на то они и публичные. На сервере контрагента зашифрованные этими ключами сообщения в Ваш адрес, которые можно расшифровать только вашими приватными ключами, которых у контрагента нигде нет. В почтовых клиентах пользователей контрагента - вероятно, да, есть и незашифрованные копии (как-то же пользователь свои отправленные должен видеть).
Но, во-первых, в почтовых клиентах не всё (очень часто предметом интереса являются весьма старые истории).
Во-вторых, сервер, вероятно, стоял в ЦОДе, и пришли туда, а не в офис. Если этот сервер - ещё и виртуалка, то, возможно, просто владельцу ЦОДа показали ордер, по которому тот тихо сделал и скопировал снэпшот так, что наш контрагент ничего и не узнал (потому что за неразглашение тайны следствия владелец ЦОДа тоже расписался). А если это не сервер, а облачный почтовый сервис - так там и приходить ни к кому иногда не надо...
В-третьих, не всё изъяли (есть удалённые сотрудники, кого-то просто нет на месте, ну и при нормально работающей охране большинство уже давно вышли с ноутами через аварийный выход, т.к. по рядовым делам, коих большинство, все маски-шоу тупо ломятся через центральный вход, где у них долго проверяют документы).
В-четвёртых, не всё изъятое смогли прочитать. И в РФ, и в большинстве других стран ни у свидетеля, ни у кого другого нет обязанности представлять ключ расшифровки / пароль от своего ноута, а количество дел, когда силовики отмораживаются и применяют меры силового воздействия, всё же пока незначительно на фоне тех, где прессуют, но без откровенного беспредела.
Если что - как минимум "в-третьих" и "в-четвёртых" - на личном опыте.
во-первых, в почтовых клиентах не всё (очень часто предметом интереса являются весьма старые истории).
Это уже какой-то максимальный уровень виляния. Напомню: мы начинали с того, что собственная служба безопасности не может превентивно предотвращать угрозы, например, разглашения коммерческой тайны. Впрочем, у меня будет контр-аргумент той же силы: да не, ищут, особенно в войне конкурентов, именно свежачок.
Во-вторых, сервер, вероятно, стоял в ЦОДе, и пришли туда, а не в офис
И туда, и туда пришли. Вот тебе, бабушка, и юрьев день. Такое бывало, причем, даже в РФ.
В-третьих
Воспользуюсь возможностью фантазировать в том же духе, что и у тебя: ... заблаговременно подсадили на компьютеры всех имеющих отношение к организации (удаленных или очных сотрудников) руткиты, через которые тихо и незаметно слили всё в режиме реального времени.
Кстати, я слышал про "долго и нудно проверяют документы". Это возможно только в том случае, если вход в здание один и только один, этот вход имеет шлюзовую систему (две двери, ни при каких обстоятельствах механика не позволяет обеим быть открытыми одновременно, вместительность шлюза - 1 человек). В остальных случаях чрезмерно рьяный охранник укладывается лицом в пол с последующим предъявлением обвинения в лучшем случае в воспрепятствовании законной деятельности (КоАП). Что же до "пока там собирали нужные бумаги, которых вечно не хватало охраннику, все сотрудники сложили рабочие компьютеры и покинули город" - тоже байки. В нужное время маски оцепляют здание так, что выход строго через кордон. И да, при необходимости список сотрудников готовится заранее, они досматриваются в самую первую очередь.
В-четвёртых... от своего ноута
Можно сразу вопрос: а какого чёрта у представителей масок делает СВОЙ ноут? Это же не рабочий, приходи да забирай немедленно свои личные вещи. Или это-таки вещдок, который по всем правилам оформили (а оформили, потому что по документам он никакой не свой, а рабочий, следовательно, на него не распространяется привилегия ст. 51 конституции)?
Я не верю ни одному слову из вышесказанного. За сим предлагаю вернуться к обсуждению того, что собственная служба безопасности резко против.
Я Вашему опыту полностью доверяю, потому что ситуации бывают разные. Но коль скоро Вы, напротив, решили обвинить меня во вранье, - продолжать обсуждение любых вопросов с Вами, естественно, не намерен. Я сюда делиться опытом и получать его прихожу, а не доказывать кому-либо что-либо, тем более в ответ на хамство. Всего хорошего.
Ключи, возможно, даже запаролены, а пароли знают только конкретные пользователи
для сущей безопасности ключи можно хранить например в hsm модуле, который окукливается при попытке его физического изъятия или по команде с охраны например, тогда можно какие хочешь ключи и пароли вспоминать, ничего не поможет
p.s. в банках подобные девайсы стоят на шифрование критичных полей БД (справедливости ради, половина элементов контроля обычно отключено, во избежание забавных трудностей из-за ошибок персонала)
Позвольте, а где (в чем) Mozilla исправила ошибку? Вместо MailNews сегодня Thunderbird, там была та же самая ошибка?
Такое ощущение, что им как будто кто-то специально мешал это сделать
Мозилла вообще произвольно с багами обращается. Лет 15 назад то ли открыл, то ли присоединился к открытому багу, что кеш браузера на виндах сохраняется в roaming часть профиля - убивая локальную сетку и производительность. Там были комментарии что кому-то это мешает развернуть Мозиллу на нескольких тысячах компов в универе. На исправление ушло 10 лет, хотя просто дефолтовый конфиг исправить.
Многие специалисты по безопасности говорят, что шифрование электронной почты должно стать стандартом, ведь тайна почтовой переписки защищена Конституцией и является одним из основных прав человека.
Какое шифрование? Кто или что мешает шифровать пользователям почту перед отправкой в почтовом клиенте, например, в Thunderbird, Kmail и другие, и использовать при этом любую криптографию.
Конечно, управление персональными сертификатами пользователями в большом масштабе сложнее, чем управлением сертификатами веб-сайтов, но это решаемая задача.
Ждём статью об этом.
Электронная почта - не мессенджер, и там стоит вопрос хранения сообщения, на сервере или на клиенте.
А с вопросом хранения встает очень интересный вопрос сертификатов с истекшим сроком действия и отозванных сертификатов.
Что должно происходить с сообщением? Если просто подписанное - то появится пометка о том что подпись просрочена, а зашифрованное - больше не расшифруется? Получается так. Ну и как итог, возникает вопрос в необходимости этого функционала в почтовом клиенте вообще: либо почтовый клиент работает в режиме месенджера и хранит расшифрованное сообщение (а если это облачный сервер?), либо вообще незачем шифровать.
Если просто подписанное — то появится пометка о том что подпись просрочена, а зашифрованное — больше не расшифруется?
1) появится
2) расшифруется (но новые уже шифровать таким ключем нельзя)
вообще история с шифрованной почтой очень сильно напоминает обмен документами в ЭДО, логика буквально 1:1
Только вот я не понимаю логику, что ЭЦП обязательно перевыпускать каждые 12...18 месяцев.
исключает ситуацию когда у вас уже 5 лет ктото украденной подписью читает переписку, в т.ч. переписку которая была за 10 лет до того как подпись украли
А, ну то-есть год можно, а 5 лет - нельзя.
Может для безопасности каждую неделю перевыпускать?
Вообще, чтобы избежать этой проблемы и придумали «костыль» в виде «цепочек доверия» и возможности «отзывать» сертификаты, по идее если есть некий «CA» которому доверяют все участники обмена - костыль работает. Можно и вручную удостоверять подписывая ключи пачками подписей…
А уж какие правила для CA будут выдуманы людьми…
Какая здесь логика — здесь закон! Если речь идет о применении ЭЦП, скажем, в рамках госуслуг. Мы же меняем паспорта.
Для внутри корпоративного использования используются свои распоряжения.
Del
P.S. Перечитал ваш комментарий, подумал, и снес свой за ненадобностью
Тут недавно была статья о том, что технических реализаций, соответствующих закону, в том числе, в государственных учреждениях, не существует. Производители решений тоже отмораживаются ответить односложно на вопрос, соответствует ли нормативному регулированию их реализация.
Паспорта меняем не каждые 18 месяцев.
Мне очень нравилась реализация PGP на штатном почтовике Blackberry. В частности на старом ещё Q10.
Такой удобной работы не видел больше ни на одном мобильном устройстве.
Почему шифрование почты за 30 лет не стало мейнстримом?