«без ключевое» шифрование конфига

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

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

тем не менее железки тырят, так что помножу ваше мнение на ноль.

железки тырят потому-что они железки и их можно стырить.

если сильно приспичило, то простейшее решение «закрыть конфиг» - класть его в шифрованный раздел, в голову не приходило ?

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

У меня от сети питание, да и нет гпс приемника

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

Приходило, в этот раздел попадать софт будет через пароль указанный в нем?

У меня от сети питание

Это как? Сразу из монтажного шкафа 220 чтоли?

Тогда будет замечательная проблема, под названием «кратковременное отключение электроэнергии», особенно если ты запитался в жилом доме.

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

В сервера даже ставят.

Может и не кратковременное, но это уже не моя проблема.

Приходило, в этот раздел попадать софт будет через пароль указанный в нем?

блин…ёпрст…какой-то чёртовый ликбез :-) раздел шифруется от аппаратных идентификатов, вас вообще не трогает как и от каких. Вы кладёте конфиг в /etc/config/tra-la-la и общаетесь с ним как с обычным файлом.

Чем шифруется? Открываю юзергид для dm-crypt где написано как создание раздела требует пароля.

А кто заставляет делать ключ текстовым? Чаще всего ключ шифрования это просто набор байтов. Да его могут в какую-то человекочитаемую форму переводить типа base64 или hex, но это не обязательно

Это тоже самое что хорить пароль и все так же хранить в бинарнике как константу, вот я глянул в свой размером всего лишь 15мб и в целом gcc константы кладет друг за другом, т.е. особо никаких трудностей найти нет, изначально конечно можно как то элементарно сделать некий хеш пароля, а потом по нему восстанавливать в рантайме, но это все равно константа.

Но есть уже мысль как просто генерировать пароль от шифрованного конфига сравнительно случайный при каждой его записи и восстановить при чтении.

а потом любой студент пишет мелко-скрипт, который подглядывает через strace за мего-защищённой тулзой и после read(config) сбрасывает его coredump. Порядка 7-ми строчек

Фсё, конфиг в открытом виде и TC потел зазря

Уже было в South Park :)

Т.е гуглить что такое «key derivation» ты принципиально отказываешься? Или это что-то религиозное?

Гугл сказал это что то вами вчера выдуманное и все.

Временами отвечая на ЛОРе приходится стараться не разбить себе лоб от фейспалмов:

https://en.wikipedia.org/wiki/Key_derivation_function

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

По сути то в чем смысл если просто не тыкать вам пальцем в небо?

А то тут аналетиги вон не знают что шифрование раздела паролем выполняется.

Суть в том что вместо полного ключа ты зашиваешь в код его часть, другую часть берешь из ID оборудования а затем вычисляешь «derivation» от полученного - другой ключ, который нигде не сохраняется. Вот им уже ты и шифруешь свои данные. Таким образом в ресурсах программы полный ключ светиться не будет а для того чтобы расшифровать данные будет нужно делать полноценный реверс-инжиниринг.

Но блин с таким уровнем в криптографию лезть точно не стоит.

Ну да, это «лучше» чем не хранить ключ в коде и не делать его по вашему совету константным, ещё про какие то деньги сочиняли за такие кривые решения.

Деньги мне обязательно заплатят, но конечно не ты а твои «конкуренты» )

Если ты с таким подходом и навыками в криптографии действительно чего-то сделаешь и запустишь.

В таких случаях я всегда желаю долгих лет такому пассажиру, пока такие есть на свете - у меня всегда будет работа ))

Конкурентов уже паламали, потом в новостях писали, так что уже можете к ним бежать вашу абстрактную чушь втирать.

Алекс тебе рабочую схему бесплатно предложил, а ты как-то не рад. Не хочешь просто-хитрый ключ, так есть еще вариант. Твоя железяка, которую обязательно свинтят «привинчена» к какой-то другой железяке? Проверяй наличие второй железяки, и, если ее нет, затирай конфиги нулями.

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

второй железки нету, это одноплатник

а чем это отличается от того, что тут писали?

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

Рид конфига при буте выполняется одновременно с другими потоками,

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

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

самопальное шифрование не поможет, это уровень студенческой лабараторки - поймать момент чтения файла и после сдампить память процесса

лучший рецепт - определить что надо защищать, а что вдоль. не держать чуствительных данных в конфигах. Если защищать то в комплексе со всей системой.

даже тупое шифрование всей ФС с ключом «васян» надёжнее чем ваши потуги, требует от злыдня большей квалификации и расхода средств (времени/денег)

аа ну т.е. все таки ключ «васян» для шифрования нужен, а не предыдущий ваш такой же выдуманный как про студента вариант, что никакой пароль для ФС не нужен.

понятно, очередной «дельный» совет.

«без ключевое»

Бесключевое.

конфиги моего ПО на них, да так чтобы ключ-пароль сей не светился в самом бинарнике.

Так запретите пользовательскому софту читать конфиги. От кражи конфигов «на холодную» спасет TPM+Measured boot.

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

… клоунада продолжена с новыми силами =D ну удачи твоему заказчику с твоим делюзиями.

)) Ога, давай досвидания, трепло

Вы бы как-то подружелюбнее к людям все же. Тут вам честно пытаются донести простую мысль: то, что вы пытаетесь соорудить – это классический Security through obscurity:

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

А вы всех лесом посылаете.

Если в ваших условиях единственное, что вы можете сделать – это тот самый security by obscurity, то печально конечно, то отвечающие вам здесь в этом не виноваты.

не всех, только тех кто рассказывает что у него чего то там невозможно и на вопрос как не хранить случайный пароль в коде - 100500 раз рассказывает какой я тупой и именно так пароль хранить надо и обязательно сделать его константным.

да, надо увеличить время на взлом и отсечь уровень «специалистов» с такими советами.

т.е. что то аля «локальная программная проверка на лицензию», конечно взламывают такое, но это не люди, которые не могут http api прикрутить к БД в несколько строк, а тут мне рассказывают как они в несколько строк чего то взломают, на пару с выдуманными студентами.

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

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

Столько советов и никто не предложил поставить рядом с железкой охранную собаку (а в ошейник собаки вставить rfid-метку с паролям к зашифрованному конфигу, мы в хакеров играем или как?).

) все это утаскивается целиком, т.к. лежит в одном ящике хоть и под замком.

Я тут вижу только один работающий вариант: специально обученный человек должен ручками ввести пароль в момент включения устройства. Всё остальное — если у устройства есть доступ к ключу, то и у злоумышленника тоже оно есть.

да это было бы не плохо, но железки работают по принципу - поставил и забыл на годы пока что то не сломается.

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