FinerLife, а почему разработчики эту задачу должны решать, если сервера доверенного времени и так прекрасно справляются?
Если не согласны со мной - расскажите своё виденье и ответьте на вопросы, которые в первой половине того комментария я оставил)
Мне неиронично интересно, как эти проблемы можно решить.
Сделать портативное устройство доверенного времени, которое будет носить с собой тот, кто будет подписывать документы невозможно по определению.
Метка доверенного времени по определению должна создаваться третьей, не заинтересованной стороной.
Какое бы хитрое и защищенное от внешнего воздействия устройство мы бы не сделали - его всё равно можно будет аккуратно вскрыть, исказить сигналы, которые оно передаёт при формировании метки доверенного времени, получить вот такой вод подписанный задним числом документ, предъявить его в каком-нибудь судебном деле, а в случае каких-то вопросов - сказать что ты это устройство потерял или оно сломалось.
В принципе если подумать - такое устройство вполне можно сделать, но нужно всех пользователей таких устройств ставить на учёт примерно как владельцев огнестрельного оружия, обязать их проходить специальную аттестацию, и проверять техническое состояние устройства каждую неделю. А в случае любого нарушения (повреждения корпуса или отставание часов хотя бы на секунду от эталона) - уголовная ответственность примерно как за подделку документов и признание недействительными всех документов, где присутствует метка доверенного времени с такого потенциально скомпрометированного устройства.
Соответственно, чтобы такое не происходило, нужно будет это устройство возвращать для корректной утилизации заблаговременно, пока часы не потеряли точность и пока батарейка не села.
Вообще если вам не нравится зависимость от УЦ при формировании метки доверенного времени, то тогда вы можете попробовать открыть самостоятельно новый УЦ
FinerLife, ну давай по порядку
1. Как ты добьёшься абсолютной точности? Как их синхронизировать?
2. Какой срок службы батарейки в этих часах? Что делать, когда она сядет?
3. Как гарантировать, что источником времени были именно эти защищённые часы?
4. Как это интегрировать с уже существующей инфраструктурой?
Вопрос был в том, можно ли встроить такие оффлайн часы в сам сертификат.
...
В данном случае батарейка для сертификата не нужна, если есть компьютер.
1. Сертификат - это обычный файл, это не физическое устройство. Ты никак в него часы не встроишь.
2. Носитель ключа следует подключать к компьютеру только для совершения криптографических операций, а после этого сразу отключать.
3. Носителем ключа вполне может быть запароленный файл на этом же компьютере, без отдельного защищённого токена.
И кто будет потом сертифицировать эти защищенные часы? Как доказать, что в этих часах действительно нельзя никак подкрутить время или "заморозить" заранее.
Допустим даже что у нас всё-таки сертификат исключительно на внешнем носителе и подпись всегда только на нём совершается.
Что мешает владельцу этого девайса его разобрать и подпаять свои часы вместо доверенных?
Ну и это же ваше предложение сделать оффлайн часы, а не "разработчиков", значит вам и нужно сначала все нюансы проработать о том, как оно должно работать.
Я больше поверю в специально обученого лейтенанта фсб с чётками
Никак. По определению
Ибо если твоя система толерантна к разделению на уровне сети и при этом остаётся доступна - она по определению не может быть на 100% консистентной, ибо тогда на разных узлах будут разные данные, ибо нет сетевой связности.
А если оставлять 100% консистетность, то тогда при разделении должна теряться доступность - узлы должны переходить в read only, пока не вернётся связность.
Так что максимум чего можно достичь - Eventual Consistency, когда в моменте данные не консистентны, но со временем изменения распределяются по всем узлам и достигается полная консистетность, либо чтобы была консистентность на основе консенсуса, а отвалившиеся узлы без возможности собрать консенсус пусть становятся недоступными.
Собственно те самые компромиссы.
Из практического:
1. Для консенсуса и автоматического выбора ведущего узла есть Raft протокол, который реализован достаточно много где. (https://raft.github.io/)
2. Для автоматического восстановления есть Viewstamped Replication Revisited (pmg.csail.mit.edu/papers/vr-revisited.pdf)
Norum, какую?
Я вот загуглил - можно новый такой купить примерно за 10к (первая строчка в поиске, возможно есть дешевле или дороже).
Самое дешевое с SFP разъемом, что я нашёл - MikroTik RB760iGS стоит примерно тех же денег, но к нему потом отдельно нужно будет докупить SFP модуль и разобраться, как его настраивать.
И в случае каких-то проблем с ним - вы никак не сможете пенять на поддержку Ростелекома и вам со всем придётся разбираться самостоятельно, в том числе если вдруг рт захочет накатить какое-то обновление на свою сеть терминалов, которое естественно не накатится на ваш модуль и у вас пропадет интернет.
Даже мясные переводчики иногда допускают ошибки при переводе игр из-за нехватки контекста и вычитки. (Например когда тупо нет самой игры перед глазами или когда разработчик не рассказал переводчикам смысл каких-то терминов)
Не так давно проходил Split Fiction как раз в переводе от нейросети (только текст) и там было очень много очевидных ляпов в переводе.
Можно ли купить звёзды через крипту?