Проверка подлинности ПО

Вопрос по поводу подлинности: верно понимаю, что проверка с помощью pub-ключа, полученного из того же источника, что и данные, имеет смыслом только самоуспокоение? Или какой-нибудь профит всё таки есть?

Хеш можно подсунуть. Сиг нет.

Как, например, лоровец проверяет (если проверяет) подлинность установочных образов Debian?

Побитно.

Сиг нет.

А можно разжевать для начинающих?

Можно и сиг подсунуть, кто помешает?

Дело в том что источник часто разный. Хеши лежат на основном сервере проекта, а образы на куче разных cdn. И вот чтобы эти cdn тебе не подсунули что-то левое, хеши и сверяют.

Можно и сиг подсунуть, кто помешает?

паб.

Что паб? Полученный по тому же каналу? Его тоже можно подсунуть.

Что паб?

разжевать для начинающих?

Алиса и Боб заплакали…

pub-ключа, полученного из того же источника

Можно получить из разных (довереннных?) источников, сравнить, и принять решение, стоит ли доверять одинаковым (разным?) ключам.

Дело в том что источник часто разный

Вернёмся к примеру с Debian. Образы, хэши и сиги у них хранятся на cdimage.debian.org, а пабы на www.debian.org. Много ли это даёт?

Можно получить из разных (довереннных?) источников, сравнить, и принять решение, стоит ли доверять одинаковым (разным?) ключам.

А можно просто получить у того, кто подписал. Привом.

получить у того, кто подписал.

Он принадлежит множеству «разных источников».

Привом.

Можно ли доверять такому каналу передачи? Надеюсь при передаче не использовались вещества изменяющие сознание (прокисший смузи)?

Договориться встретиться в условленном месте. При встрече вести себя как старые друзья, зайти в кафе и общаться на отвлеченные темы. Вечером погулять по городу, посмотреть достопримечательности. Ночью закрыть занавесками/жалюзи окна и выключить свет. Лечь в одну постель, накрыться одеялом. Самое время обменяться хэшем. Шептать на ухо плохой вариант - могут подслушать. Не следует использовать ручку - ее могли подменить. Лучший вариант - передающий должен по памяти чертить пальцами по коже принимающего символы, принимающий должен их запоминать.

Да, это как раз и есть разные источники.

Да. Все так.

Все эти подписи и хеши бессмысленны если нет доверенного источника публичных ключей.

Все эти подписи и хеши бессмысленны если нет доверенного источника публичных ключей.

Думаю, хозяина приватного из пары можно считать достаточно доверенным )))

А как же передать азбукой морзе через фрикции?

Может подслушать сосед

Ну зачем же.

Есть же инфрастуктура ключей от openpgp.

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

Так же там можно и цепочки доверия реализовывать.

Вроде убунтята это даже используют, и мантейнеры репов и самих образов.

Может подслушать сосед

Пусть слушает. У нас свободная страна публичный ключ. )

Зачем делиться чем-то личным в интимной обстановке? Это уже небезопасно, можно подхватить кокошниковирус. Лучше делится со всеми своим показным счастьем, чем больше людей знает о твоём счастье, тем лучше.

Хэш не нужен. Вычисляете его по месту. Проверяете подпись и всё. Всё что нужно – иметь доверенный публичный ключ.

верно понимаю, что проверка с помощью pub-ключа, полученного из того же источника, что и данные, имеет смыслом только самоуспокоение?

Неверно. Если источник доверенный, то дынным есть доверие и без подписи.

Если источник не доверенный, то доверия публичному ключу нету. И проверять им подпись не имеет смысла. Самоуспокоение в данном случае наступать не должно. Должен наступать поиск доверенного источника публичного ключа.

доверия публичному ключу нету

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

Стабильность.

Вопрос по поводу подлинности: верно понимаю, что проверка с помощью pub-ключа, полученного из того же источника, что и данные, имеет смыслом только самоуспокоение? Или какой-нибудь профит всё таки есть?

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

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

Конверт с сургучной печатью?

https://www.openbsd.org/papers/bsdcan-signify.html

Конверт с сургучной печатью?

Джонни Мнемоник с клеймом флешкой на в заду мозгу.

ТРК заиграет новыми красками )

Есть же инфрастуктура ключей от openpgp

Понимаю, что вопрос не к вам, но почему разработчики так редко публикуют туда ссылки? Например, на вскидку увиденного за последние 2 дня: Raspberry Pi OS, Debian, GNU Guix, XZ Utils и сам GnuPG — у всех в руководствах по проверке ссылки на пабы ведут на свои же ресурсы, а часто на то же место, где и данные.

Можно использовать два недоверенных источника из разных юрисдикций. Если ключ с американского сервера, а образ с Яндекса, то шанс, что оба будут подменены и подменены одним и тем же лицом (чтобы совпал ключ и образ) ниже. Аналогично можно качать через разных провайдеров, разные VPN и т. д. Суть даже не в том, чтобы ключ не подменили, а в том чтобы не подменили одинаковым образом.

Плюс можно мониторить изменения ключа. Образы скачиваются многократно (так как они обновляются, так как они много весят и их может быть накладно хранить), а ключ можно хранить долго.

Можно использовать два недоверенных источника из разных юрисдикций.

Усложнить себе жизнь, не получив гарантий.

Поставщик, который что-то там подписывает, и предоставляет публичный ключ. И способ его получения. Это его работа. Иначе все его подписи не стоят и выеденного яйца.

Если он этого не делает, то нужно к нему обратиться. Пусть делает. Либо сменить поставщика.

Это так и делается. Просто поставщик предоставляет данные и публичные ключи. Но, возможно, проще получать данные (не ключи) с зеркал. По скорости. На зеркалах данные берутся из доверенного источника. У поставщика. Но зеркалу доверия нету. Подпись даёт это доверие.

Тебе подлинность ПО или дистрибутива ОС? Это большая разница, тот же дебиан вообще грузит пакеты по http и все окей, в случае не соответствия контрольной суммы ругается и не ставит пакет, проверял лично лет 15 назад, когда доморощенный админ блочил урл включающий слово proxy.

OpenPGP это когда каждый сам себе удостоверяющий центр. OpenPGP это не быстро, а многолетний кропотливый труд. Начать никогда не поздно, но лучше со школы. Помните, OpenPGP очень ненавидят АНБ, КГБ, ФСБ и прочие *Б. OpenPGP полная противоположность анонимности, для работы вам необходимо верифицировать людей по фотографии в паспорте, проверять их Ф.И.О. и E-mail. Чтобы OpenPGP заработал:

1. Приобрести аппаратное хранилище ключей: nitrokey или solokey.
2. Прочесть документацию о использовании OpenPGP. Общую и практику в дистрибутивах: ALTLinux, Arch, … https://www.opennet.ru/docs/RUS/pgupg/index.html https://www.opennet.ru/docs/RUS/gph/index.html https://www.altlinux.org/%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0_%D1%81_%D0%BA%D0%BB%D1%8E%D1%87%D0%B0%D0%BC%D0%B8_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA%D0%B0
3. Создать свою пару приватного и публичного ключа.
4. Сбекапить приватные ключи paperkey.
5. Записать приватные ключи в аппаратное хранилище и уничтожить с помощью shred их копии на компьютере.
6. Подписать своим приватным ключом публичные ключи своих одноклассников, однокурсников, сотрудников которых ты долго и очень хорошо знаешь. Проверять по паспорту: фотографию, Ф.И.О, верифицировать E-mail.
7. Залить свои подписи публичных ключей верифицированных знакомых на публичные сервера ключей OpenPGP.

gpg --list-keys --with-sig-check
gpg --check-trustdb

Через пару лет твоей кропотливой работы как удостоверяющего центра (подписи публичных ключей хорошо знакомых и верифицированных по паспорту) получатся цепочки доверия к другим публичным ключам, людей которых ты никогда не видел. Если к ключу есть больше трёх цепочек доверия его можно считать относительно надёжно верифицированным и можно относительно доверять.

Пример цепочек доверия: https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs

Можно по началу срезать углы и принять за доверительные ключи разрабов распространяемые с вашим дистрибутивом:

• https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/keys
• https://packages.gentoo.org/categories/sec-keys
• http://git.altlinux.org/gears/a/alt-gpgkeys.git?p=alt-gpgkeys.git;a=tree;f=keys;h=8e4681ca9a86ff414473358b01ce8ad79b59cc38;hb=HEAD

да да

You can read it out loud over the phone in under a minute. Wide dispersion makes it harder and harder to intercept all the ways you may get the key and increases the risk of detection should anybody try some funny business.

Идея взять на поиграться ключи OpenPGP с вашего дистрибутива не самая плохая.

• https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/keys
• https://packages.gentoo.org/categories/sec-keys
• https://git.altlinux.org/gears/a/alt-gpgkeys.git?p=alt-gpgkeys.git;a=tree;f=keys;hb=HEAD
• • Накачать скриптом рекурсивно недостающие ключи с серверов ключей OpenPGP.

Для экспериментов такого рода лучше создать отдельного пользователя и перед каждым действием бекапить каталог .gnupg

Можно рекурсивно докачать с серверов ключей публичные ключи подписей ключей с вывода gpg --list-keys --with-sig-check и построить у себя цепочки доверия к интересующим вас ключам.

Самое главное:

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

Кто чат-гопоту на форум пустил? Ану кыш кыш!

Брысь невежда.

проверить есть ли измененные файлы

sudo apt install debsums
sudo debsums -ca

Плохой, но очень быстрый способ получить публичные ключи OpenPGP. Возможно кто примет ключи полученные таким образом с минимальным уровнем доверия:

http://git.altlinux.org/gears/a/alt-gpgkeys.git
296D6F29A020808E8717A8842DB5BD89A340AEB7
3F07F25C98B6714D8809C8DFDE504C15D098D624

https://git.archlinux.org/archlinux-keyring.git
BD84DE71F493DF6814B0167254EDC91609BC9183

https://gitlab.com/ARCHLabs/archlabs_repo/raw/master/x86_64/archlabs-keyring-2019.10.06-1-x86_64.pkg.tar.xz
https://gitlab.com/ARCHLabs/archlabs_repo/raw/master/x86_64/archlabs-keyring-2019.10.06-1-x86_64.pkg.tar.xz.sig
9E4F11C6A072942A7B3FD3B0B81EB14A09A25EB0

https://github.com/artix-linux/artix-keyring.git
A55C3F1BA61CAA63036D82BAFA91071797BEEEC2

https://github.com/BlackArch/blackarch-keyring.git

https://github.com/BunsenLabs/bunsen-keyring.git

https://chromium.googlesource.com/chromiumos/platform/release-keys

rsync://keyring.debian.org:873/keyrings
60B3093D96108E5CB97142EFE2F63B4353F45989
https://packages.gentoo.org/packages/app-crypt/debian-archive-keyring

https://github.com/xsuchy/distribution-gpg-keys.git

https://github.com/endlessm/eos-keyring.git

https://github.com/finnix/finnix-keyring-pkg.git

https://gitlab.com/kalilinux/packages/kali-archive-keyring.git
3E4FB7117877F589DBCF06D6E619045DF2AC729A
D7CDB78351109E12752EC6D203881DABEBC29AB9
https://packages.gentoo.org/packages/app-crypt/kali-archive-keyring

https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git

https://github.com/netrunner-kubuntu-legacy/netrunner-keyring.git

https://source.puri.sm/pureos/core/pureos-archive-keyring.git
D33A3F0CA16B0ACC51A60738494C8A5FBF4DECEB

https://github.com/QubesOS/qubes-secpack.git
427F11FD0FAA4B080123F01CDDFA1A3E36879494
2D1771FE4D767EDC76B089FAD655A4F21830E06A

https://packages.gentoo.org/packages/app-crypt/ubuntu-keyring

Если у кого есть новые ссылки на git репозитории с ключами разрабов СПО можете здесь поделится. Особенно ценны репозитории git заверенные ключом OpenPGP, вместе с ссылками публикуйте их отпечатки.

подпись инсталяционных образов ключами c PKI ?? прикольно, но не видел.
но тут как обычно всего лишь сдвиг токи зрения: с доверия источников на доверие PKI :)

мне хватает доверия в виде торрент-файла образа дебиана, взятого с оф.сайта.
тут тебе аккурат «все в одном»: и скачивание в кучу потоков и докачка если обрыв и хеш-подтверждение скачанного для доверия.

При работе с открытыми ключами вы не можете доверять:

• Скачанному публичному ключу по https с официального сайта.
• Скачанному публичному ключу с любых серверов ключей.
• Скачанному публичному ключу по rsync, torrent, git, …

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

Вариант подписи публичного ключа аккредитованным удостоверяющим центром можно условно рассматривать как доверительный. Вы должны как то получить цепочку доверия между вашим ключом и ключом организации выдавшим аккредитацию (минцифры). Ключу минцифры сказанному по https доверять нельзя.

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

о чем и говорю, всегда есть какая-то система, которая считается доверенной. будь то сайт или цепочка доверия.
корневой ключ цепочки доверия тоже можно подделать.
данные на сайте тоже можно считать доверенным, ибо в нем тоже есть цепочка доверия :)
опять же, все упирается в то, чему ты доверяешь.
в любой системе есть условия при которых она становится доверенной.

В OpenPGP корнем доверия есть личный, созданный лично вами ключ. Он так и помечен fully trusted. Ко всему остальному, от этого ключа, должна быть выстроена цепочка доверия. И все другие ключи в OpenPGP полного доверия никогда не имеют. OpenPGP множество раз подвергалась атакам, следы этих атак сохраняются вечно, по этому сегодня для приемлемого уровня доверия к ключу необходимо более трёх разных цепочек! Вот очень хорошая и очень правильный топик на ЛОРе по данной теме описывающая создание цепочек доверия к нужным публичным ключам: А как на деле воспользоваться web of trust? (комментарий)

В X509, HTTPS есть корневые серты CA распространяемые с OS или браузерами для построения цепочек доверия от них к ключам сайтов. Любой, из более чем 100 владельцев корневых CA может сделать вам MitM!!! Верификация сертов CA X509 это другая тема, хотя…

красивое :) а теперь покажи прикладное использование данной системы.

Примеры OpenPGP:

Некоторые сообщества разработки ПО:

Linux: https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs

Проверка подлинности ПО (комментарий)

OpenPGP требует затрат от пользователей и репозитории pip, npm, … не могут ее тотально внедрить.

Шифрование E-mail. Сновдену помогло, а АНБ нет.

WoT веб оф траст широко применялся до лета 2019 года: https://www.opennet.ru/opennews/art.shtml?num=51006 Атака на сервера ключей сильно ударила по OpenPGP. На сегодня я альтернативы не вижу.

Удивляет что оно до сих пор держит удар и живо.

США запрещает экспорт: «Due to former U.S. export restrictions on cryptographic software, the software is not distributed via the standard GNU archives but from the European based GnuPG server.»

В РФ за крыптуху 5 лет дают.

Ну, если хочется более надёжной проверки, надо проверять ключ на самых разных зеркалах. Если везде один и тот же ключ, то он правильный. Также неплохо бы смотреть ID ключа и импортировать его из PKI.

теория - теорией эт много чего можно услышать.
ты по существу темы ответь :)

т.е. прикладной пример выложенного образа (да фуй с ним просто файла) с подтверждением через сеть доверия GPG.
скачать и проверить «через три цепочки»…

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

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

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

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

Но, если они хакнули и официальный источник распространения и подменили там хеш в html для проверки, то всё. Каюк.

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