Файл характеризующий конкретную ОС

Только версию ядра /proc/sys/kernel/version, но если систему перустанавливают с тем же неперекомпиленным ядром, то он и не поменяется.

А что значит переустановка системы? Бэкап из тара считается?

Можно ещё посчитать хэш от таблицы разделов на диске и UUID файловой системы в надежде, что пользователь их не менял.

Ситуация вынуждает иметь файлик или группу файликов, которые создаются только в ОЗУ (например файлы из /proc или /sys подходят замечательно) и их низя вытянуть с винта, когда тот используется не в своей родной ОС (например, если этот винт подключить просто к другой ОС). Но еще одним криетрием должен обладать файл – это быть уникальным только на той ОС на которой его смотрят.
Другими словами файлик поидеии должен существовать неизменно только пока запущенна только ЭТА ОС. При перезагрузки он должен остаться неизменным.
Я думаю, что возможно, когда загружена ОС, то есть какойнить такой файлик в /proc, который корнями уходит в пароли пользователей или чтото подобное такое, что остается неизменным на всем протяжении жизни ОС.
Такой файлик можно использовать как ключ для зашифровки и расшифровки чегонибудь автоматом.

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

А что пользователи не могут поменять пароли? Даже если Вы напишете патч для ядра, который пытается снять отпечаток системы, то эти параметры всегда можно воспроизвести и на другой ОС.

Это нерешаемо, как защита от копирования. Максимум, что можно снять – это параметры железа.

С одной лишь разницей можно это будет воспроизвести и на другой ОС – если знать пароли юзверей.
Поэтому допустим что пароли юзверей знаем только мы (только мы можем воссоздать системы с такими паролями) и они (пароли) не будут изменятся.
Тогда реально?

Вы лучше яснее опишите модель угрозы, – тогда будет ясно и решение.

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

Поэтому допустим что пароли юзверей знаем только мы (только мы можем воссоздать системы с такими паролями) и они (пароли) не будут изменятся.
Тогда реально?

Тогда реально снять хэш с /etc/shadow

cat /etc/shadow | grep root | md5sum

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

Можно, наверное и патч к ядру сделать, который отображает результат в /proc. Только непонятно для чего увязывать пароли пользователей (даже рутА) и криптографическую защиту?

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

Именно такие идеи и крутятся у меня в голове... есть еще более продвинутые идеии на данную тему?

Есть законченный ответ: защита от копирования принципиально не реалищзуема. Так устроен мир. Обратитесь в другую вселенную :)

А как-же аппаратные ключи? А концепция trusted computing?

В конечном счёте, аппаратные ключи не решают проблему. Теоретически, любую программу можно декомпилировать, вырезать из неё соответствующие компоненты, использующие обработку с лицензионным ключом, или реализовать некоторую эмуляцию (зависит от сложности самого ключа). А Trusted Computing — это не средство DRM, но некоторые организации очень хотят из него сделать именно это.

Теоретически, любую программу можно декомпилировать

...

Ну а если некоторые (существенные) части программы зашиты в "ключе" и в нём же и выполняются (находящимся же в ключе отдельным процессором) ?

А Trusted Computing — это не средство DRM, но некоторые организации очень хотят из него сделать именно это.

Ну и какое же свойство этой вселенной может им в этом помешать ?

Ну а если некоторые (существенные) части программы зашиты в «ключе» и в нём же и выполняются (находящимся же в ключе отдельным процессором)?

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

А Trusted Computing — это не средство DRM, но некоторые организации очень хотят из него сделать именно это.

Ну и какое же свойство этой вселенной может им в этом помешать ?

Никаких, но это политическое решение, а не техническое. Просто последите за общественной дискуссией вокруг Windows Vista и желании MS использовать TCM'ы в качестве DRM-платформы этой системы. Есть и ещё одна сложность: если Вы завязываете DRM-составляющую на TCM, то программа не будет работать на неTCM-системах, чем существенно сужаете рынок сбыта.

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

Очевидно, теорема о том, что теоретически любое квантовое состояние заведомо может быть склонировано с любой наперёд заданной точностью.

В меру тех тенденций, которые я вижу, скоро всё будет GPL или BSD-license. Нужно успевать за временем. Причём сей факт касается вообще любой информации.