Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
а нам пока остается ставить компьютер на виброгасящие поверхностиВиброгасящая поверхность не поможет никак, если шумят сами элементы цепей питания
Но жесткие конструкции корпуса (без демпферов) являются очень хорошим проводником звука. Особенно алюминиевые корпуса. Но это только малая толика акустического поля.
а например, просмотри видеофильма на компьютере во время шифрования не поможет никак?
Поможет любое снижение ресурсов процессора выделенных на шифрование и занятие свободных ресурсов другими задачами. Но только снизит уровень акустического и ЭМИ, саму возможность перехвата не исключит.
Вы затронули очень интересную и необычную тематику, отметил и статью и выше.
Прочитал как топик, так и статью «Механизм генерации помех в БИС процессорах».
Интересные сведения:
Статья была опубликована в 2002 году. Интересует ответы на вопросы:
1. До каких значений может простираться спектр помех на современных рабочих частотах процессоров, уменьшенном технологическом процессе и с учетом увеличенного числа работающих ключей?
2. Как часто могут случаться упомянутые резонансные явления?
3. Стала ли проблема шумов в наше время основной?
Прочитал как топик, так и статью «Механизм генерации помех в БИС процессорах».
Интересные сведения:
— чем тоньше технологический процесс тем меньше время переключения и тем выше частота генерируемых помех;
— не рассматриваются резонансные явления (хотя при определённых ситуациях они могут возникать);
— напряжение помехи растет пропорционально числу транзисторов на кристалле. Оно, при определённых условиях, может достигать порога помехоустойчивости и привести к сбоям процессора. Можно сказать так же, что, не смотря на то что, величина суммарной помехи растет пропорционально корню квадратному из числа работающих ключей, прогнозируемое Intel увеличение числа транзисторов до 400 миллионов на процессор сделает проблему шумов более ощутимой и переведет её в категорию основных;
— Мощность помех генерируемых процессором распределены во всем диапазоне ее частот, группируясь в районе тактовых частот узлов процессора.
Причем спектральный состав помехи зависит и от алгоритмов работы программного обеспечения и поэтому меняется в процессе работы.
Статья была опубликована в 2002 году. Интересует ответы на вопросы:
1. До каких значений может простираться спектр помех на современных рабочих частотах процессоров, уменьшенном технологическом процессе и с учетом увеличенного числа работающих ключей?
2. Как часто могут случаться упомянутые резонансные явления?
3. Стала ли проблема шумов в наше время основной?
1. Верхняя граница генерируемой помехи определяется как fгр = 1|tи. Т.е с уменьшением времени переключения она растет. Чтобы снизить влияние помех и набирается множество SMD керамических конденсаторов на процессоре. AMD вводил даже такой конденсатор в структуру процессора и получили положительный эффект.
2. Резонансные явления я не рассматриваю, потому что мои подсчеты показывали низкую добротность этих цепей для тех частот которые имеют место.
3. Все время идет гонка на грани. Но она ограничила тактовую частоту процессора. Со времени написания статьи по ссылке тактовая частота практически не растет.
2. Резонансные явления я не рассматриваю, потому что мои подсчеты показывали низкую добротность этих цепей для тех частот которые имеют место.
3. Все время идет гонка на грани. Но она ограничила тактовую частоту процессора. Со времени написания статьи по ссылке тактовая частота практически не растет.
Объяснение куда проще — свистят подсыхающие электролиты.
Объяснение куда проще — свистят подсыхающие электролиты.А не индуктивность? Обычно именно катушки заливают эпоксидкой, чтобы уменьшить свист
Думаю, что вы оба правы — и электролиты, и катушки, но то, что отметил автор статьи — это что-то новенькое и интересное. И очень похоже на правду, особенно с учетом той статьи, на которую он ссылается.
А проверить, кстати, очень просто. Подключить керамический SMD конденсатор к генератору звуковых (ультразвуковых) частот и прощупать излучения микрофоном.
Микрофон к осциллографу — напрямую или через усилитель. Если зафиксируем сигнал, изменяющийся в такт колебаниям генератора, значит, SMD-конденсатор «звенит». Интересно узнать — в какой степени это происходит. Предполагаю, что чем ближе к прямоугольнику будет подаваться сигнал на конденсатор, тем отчетливее должен быть «звон».
Я тоже всегда был уверен, что «свистят катушки» (детские эксперименты с проводной радиоточкой — при втыкании в неё силового трансформатора со снятым уплотнением вокруг металлических пластин трансформатор начинал «говорить», причём даже разборчиво). Однако, оказалось, что нет, это конденсаторы, причём не только в компьютерах, но, и, например, в кондиционерах.
К сожалению не все катушки заливают эпоксидкой, да и магнитострикция работает (звучат и сердечники)
Конечно. И именно уменьшить, а не исключить. Исключить можно только применением звукопоглощающих материалов, а они обладают плохой теплопроводностью и потому не применяются.
Расслабитесь люди, просто попытайтесь понять КАК именно происходит утечка!
Скажем есть некий известный алгоритм, хорошо известный и сильно оптимизированный.
Его выполнение на ЦП процесс нудный, однообразный и загрузный, так что наблюдая за спектром помех наводимых девайсом мы можем с большой вероятностью идентифицировать его, а за одно и прикинуть время его исполнения, которое отчасти скомпрометирует исходные данные :-)
На самом деле, анализ ЭМП используется давно и широко, а акустика она не так интересна, порядок частот ниже, так-что времени наблюдения требуется на порядок больше, и при этом погрешность измерений большая…
Скажем есть некий известный алгоритм, хорошо известный и сильно оптимизированный.
Его выполнение на ЦП процесс нудный, однообразный и загрузный, так что наблюдая за спектром помех наводимых девайсом мы можем с большой вероятностью идентифицировать его, а за одно и прикинуть время его исполнения, которое отчасти скомпрометирует исходные данные :-)
На самом деле, анализ ЭМП используется давно и широко, а акустика она не так интересна, порядок частот ниже, так-что времени наблюдения требуется на порядок больше, и при этом погрешность измерений большая…
Вы правы — именно нудный (циклическкий — постоянно повторяющийся) и поэтому его проще всего снять.
Может быть акустика и не так интересна, но она лишнее подтверждение наличия комплексной проблемы высокого уровня электромагнитного излучения и наличия проблемы. А вот ЭМИ имеет более высокие верхние частоты.
Может быть акустика и не так интересна, но она лишнее подтверждение наличия комплексной проблемы высокого уровня электромагнитного излучения и наличия проблемы. А вот ЭМИ имеет более высокие верхние частоты.
я конечно понимаю, что компьютер шумит, но хоть убейте не могу поверить, что это можно использовать для извлечения ключа шифра.
на компьютере одновременно работает множество процессов — их поведение в общем случае хаотично и непредсказуемо. Антивирус иногда периодически сканирует файлы. Скайп опрашивает статусы абонентов по сети. Браузер обновляет страницы и прокручивает баннеры.
Запустите на ПК ProcessMonitor и посмотрите как много процессов одновременно выполняют массы работы — читают файлы принимают — отправляют по сети, обращаются к реестру. Как среди этой рутинной хаотичной работы можно выявить что-то?
В конце концов, частота процессора 2ГГц. А частота звука 20КГц.
За один интервал звуковой выборки процессор выполнит 100000 команд процессора!
Не удивлюсь что фтого числа хватит для шифрования целого блока данных.
на компьютере одновременно работает множество процессов — их поведение в общем случае хаотично и непредсказуемо. Антивирус иногда периодически сканирует файлы. Скайп опрашивает статусы абонентов по сети. Браузер обновляет страницы и прокручивает баннеры.
Запустите на ПК ProcessMonitor и посмотрите как много процессов одновременно выполняют массы работы — читают файлы принимают — отправляют по сети, обращаются к реестру. Как среди этой рутинной хаотичной работы можно выявить что-то?
В конце концов, частота процессора 2ГГц. А частота звука 20КГц.
За один интервал звуковой выборки процессор выполнит 100000 команд процессора!
Не удивлюсь что фтого числа хватит для шифрования целого блока данных.
Циклически повторяющиеся действия выделить легче всего (шифрование). И потом наличие специфического шума подтверждается не только моими старыми исследованиями, но и получением Ади Шамиром положительного результата по извлечению ключа. Почитайте первоисточник.
Другие действия (например простой съем текущей информации) имеет свои имеет свою специфику.
Как пишет Ади Шамир акустическое поле имеет спектр до сотен килогерц.
И еще свойство фильтров в цепи питания процессора не в состоянии полностью погасить помеху за счет эффекта интегрирования, постоянная интегрирования величина переменная потому что Ri эквивалентного генератора помех меняется.
Другие действия (например простой съем текущей информации) имеет свои имеет свою специфику.
Как пишет Ади Шамир акустическое поле имеет спектр до сотен килогерц.
И еще свойство фильтров в цепи питания процессора не в состоянии полностью погасить помеху за счет эффекта интегрирования, постоянная интегрирования величина переменная потому что Ri эквивалентного генератора помех меняется.
циклических и повторяющихся действий в компьютере вагон и маленькая тележка.
Это и регенерация экрана контроллером дисплея и опрос таблиц транзакций USB контроллерами.и обработка цикла сообщений окнами виндовс.
Это и регенерация экрана контроллером дисплея и опрос таблиц транзакций USB контроллерами.и обработка цикла сообщений окнами виндовс.
Но не все они так грузят проц.
у меня на ноутбуке почти всегда включен VPN к удаленному офису, кроме этого, открыт Скайп, который якобы шифрует аудио и видео трафик и браузер к некоторым страницам https.
Эти приложения что-то когда-то шифруют, но я их не замечаю, не заметны какие либо тормоза при их использовании.
Реально грузит процессор компиляция большого проекта Altera Quartus II — вот это я вижу.
Загруженный процессор не есть признак того, что компьютер в настоящий момент шифрует.
Эти приложения что-то когда-то шифруют, но я их не замечаю, не заметны какие либо тормоза при их использовании.
Реально грузит процессор компиляция большого проекта Altera Quartus II — вот это я вижу.
Загруженный процессор не есть признак того, что компьютер в настоящий момент шифрует.
Конечно нет. Просто когда процессор загружен на 100% шифрованием сигнал акустической волны зарегистрировать легче. Мощность акустической волны в этом случае максимальна.
А Скайп шифрует, но шифрует достаточно быстро с короткими ключами. И тормоза в Скайпе можно почувствовать, только когда одновременно работают другие «тяжелые» программы.
А Скайп шифрует, но шифрует достаточно быстро с короткими ключами. И тормоза в Скайпе можно почувствовать, только когда одновременно работают другие «тяжелые» программы.
Только частоты там — гигагерцы. А свистит оно на килогрерцах. За один излучаемый звуковой период процессор от отдной до десятка тысяч операций выполнит — как прикажете дешифровать? А ещё кэш есть и шина и свит отражает чёрте что, но не просто работу процессора.
На сотнях килогерц. Я уже писал об интегрирующих свойствах имеющегося в цепи питания фильтра.
Но самое главное, что анализ спектра позволяет выявить закономерность.
Но самое главное, что анализ спектра позволяет выявить закономерность.
Это конечно сложно понять, но если у нас имеется достаточно много данных по выполнению блоков некоего алгоритма по 10тыс тактов на каждую извлеченную суммарную характеристику но в разной фазе у нас есть шансы узнать в подробностях практически про каждый из тактов. Таким же образом восстанавливают размытые изображения, когда каждая точка изображения зависит от сотен соседних но у нас есть тысячи и миллионы точек которые тоже в некоторой степени зависят от части тех же точек в конце концов складывается система зависимостей которую можно решить. Всё это задачи достаточно сложны, но решаемы.
Боюсь, что не так. Ничего там не поймёшь. Работают ядра процессора. Независимо. «Параллельно» работает суперскалярное исполнение. Из-за этого картина потребления даже на практически одинаковом алгоритме будет разная. Параллельно и практически асинхронно работает огромный (по числу транзисторов) кэш второго/третьего уровня, который потребляет никак не меньше ядер. А значит и «шумит» он не меньше. И данные в этом кэше всегда будут разные — хоть тресни. Это, кстати, основной аргумент. В это же время параллельно и асинхронно работают шины. Работает контроллер памяти. а если ещё и встроенный GPU работает… Ничего там нельзя понять. Особенно учитывая, что нагрузка зависит не от данных а от кода. Один только спектр получается сужается даже не 1000 раз, как простая зависимость частот, а порядков на шесть, минимум. С тем уже успехом можно попытаться прочитать мысли человека, сняв энцефалограмму через кирпичную стену — на мой взгляд задача обработки даже проще будет.
Могу только посоветовать посмотреть термограмму процессора. Это упорядочит Ваше представление о загрузке узлов процессора.
И еще не забывайте, что работа узлов процессора синхронизируется из одного источника.
И еще не забывайте, что работа узлов процессора синхронизируется из одного источника.
Не все так просто с синхронизацией. Источник один, но latency узлов разное. В результате состояния узлов процессора разные и не повторяющиеся. Поэтому какие-то узлы вычислительных ядер несомненно срабатывают одновременно, например, с какими-то узлами кэш-памяти. Но какие именно предсказать нельзя (зависит от предыстории) и они будут всё время разные.
Конечно, когда процессор начинает выполнять произвольные команды то так и будет.
Но алгоритмы шифрования довольно упорядочены, и их поведение очень сильно зависит от исходных данных. особенно условные переходы. Конечно нельзя будет восстановить пошагово работу программы, но спустится можно до уровня исполняемых блоков, учитывая что такие вещи часто пишут на ЯВУ эти блоки могут быть довольно таки крупными и давать характерные отпечатки.
Но алгоритмы шифрования довольно упорядочены, и их поведение очень сильно зависит от исходных данных. особенно условные переходы. Конечно нельзя будет восстановить пошагово работу программы, но спустится можно до уровня исполняемых блоков, учитывая что такие вещи часто пишут на ЯВУ эти блоки могут быть довольно таки крупными и давать характерные отпечатки.
В конце концов, частота процессора 2ГГц. А частота звука 20КГц.
Это частота, которую вы слышите, т.е. ощущаете ушами, до 20КГц (на самом деле, где-то до 16). А частота акустических (звуковых) колебаний может быть гораздо больше — это называется «ультразвук». Это же просто колебания кристаллической решётки, плотности атомов воздуха и тому подобного. Нечего удивляться, что микрофоны могут снимать бОльшие частоты, чем уши.
хорошо, звук 100кГц.
Процессор 2ГГц, четырех ядерный i5 — эквивалент 10ГГц если загрузить все ядра.
10000000000.100000 = 100000 команд процессора на одну звуковую выборку…
Если посмотреть на процедуру шифрования RC5
?RC5Encrypt@@YAXPBEPAE@Z PROC; RC5Encrypt, COMDAT
; 153: {
push ebp
mov ebp, esp
; 154: const ULONG *sptr = (PULONG)sTable;
; 155: ULONG a, b;
; 156:
; 157: GetBlockLittleEndian(in, a, b);
; 158: a += sptr[0];
mov ecx, DWORD PTR _in$[ebp]
mov eax, DWORD PTR [ecx]
; 159: b += sptr[1];
mov edx, DWORD PTR [ecx+4]
add eax, DWORD PTR ?sTable@@3PAKA
add edx, DWORD PTR ?sTable@@3PAKA+4
push esi
push edi
; 160: sptr += 2;
; 161:
; 162: for(unsigned i=0; i<r; i++)
mov edi, DWORD PTR ?r@@3KA; r
xor esi, esi
test edi, edi
je SHORT $LN16@RC5Encrypt
push ebx
$LL17@RC5Encrypt:
; 163: {
; 164: a = rotlMod(a^b,b) + sptr[2*i+0];
mov ecx, edx
xor eax, edx
and ecx, 31; 0000001fH
rol eax, cl
inc esi
add eax, DWORD PTR ?sTable@@3PAKA[esi*8]
; 165: b = rotlMod(a^b,a) + sptr[2*i+1];
mov ecx, eax
xor edx, eax
and ecx, 31; 0000001fH
rol edx, cl
add edx, DWORD PTR ?sTable@@3PAKA[esi*8+4]
cmp esi, edi
jb SHORT $LL17@RC5Encrypt
pop ebx
$LN16@RC5Encrypt:
; 166: }
; 167:
; 168: PutBlockLittleEndian(out, a, b);
mov ecx, DWORD PTR _out$[ebp]
pop edi
mov DWORD PTR [ecx+4], edx
mov DWORD PTR [ecx], eax
pop esi
; 169: }
pop ebp
ret 0
?RC5Encrypt@@YAXPBEPAE@Z ENDP
21 вне цикла и 13 команд (два вызова rotlMod) внутри цикла по числу раундов шифрования.
Если раундов, анпример 64, то получаем 64*13+21 = .853 команды процессора на блок данных 8 байт.
Получается, за время 1 звуковой выборки при ультразвуке 100КГц процессор зашифрует почти килобайт данных.
За секунду процессор зашифрует 100Мбайт данных.
Процессор 2ГГц, четырех ядерный i5 — эквивалент 10ГГц если загрузить все ядра.
10000000000.100000 = 100000 команд процессора на одну звуковую выборку…
Если посмотреть на процедуру шифрования RC5
?RC5Encrypt@@YAXPBEPAE@Z PROC; RC5Encrypt, COMDAT
; 153: {
push ebp
mov ebp, esp
; 154: const ULONG *sptr = (PULONG)sTable;
; 155: ULONG a, b;
; 156:
; 157: GetBlockLittleEndian(in, a, b);
; 158: a += sptr[0];
mov ecx, DWORD PTR _in$[ebp]
mov eax, DWORD PTR [ecx]
; 159: b += sptr[1];
mov edx, DWORD PTR [ecx+4]
add eax, DWORD PTR ?sTable@@3PAKA
add edx, DWORD PTR ?sTable@@3PAKA+4
push esi
push edi
; 160: sptr += 2;
; 161:
; 162: for(unsigned i=0; i<r; i++)
mov edi, DWORD PTR ?r@@3KA; r
xor esi, esi
test edi, edi
je SHORT $LN16@RC5Encrypt
push ebx
$LL17@RC5Encrypt:
; 163: {
; 164: a = rotlMod(a^b,b) + sptr[2*i+0];
mov ecx, edx
xor eax, edx
and ecx, 31; 0000001fH
rol eax, cl
inc esi
add eax, DWORD PTR ?sTable@@3PAKA[esi*8]
; 165: b = rotlMod(a^b,a) + sptr[2*i+1];
mov ecx, eax
xor edx, eax
and ecx, 31; 0000001fH
rol edx, cl
add edx, DWORD PTR ?sTable@@3PAKA[esi*8+4]
cmp esi, edi
jb SHORT $LL17@RC5Encrypt
pop ebx
$LN16@RC5Encrypt:
; 166: }
; 167:
; 168: PutBlockLittleEndian(out, a, b);
mov ecx, DWORD PTR _out$[ebp]
pop edi
mov DWORD PTR [ecx+4], edx
mov DWORD PTR [ecx], eax
pop esi
; 169: }
pop ebp
ret 0
?RC5Encrypt@@YAXPBEPAE@Z ENDP
21 вне цикла и 13 команд (два вызова rotlMod) внутри цикла по числу раундов шифрования.
Если раундов, анпример 64, то получаем 64*13+21 = .853 команды процессора на блок данных 8 байт.
Получается, за время 1 звуковой выборки при ультразвуке 100КГц процессор зашифрует почти килобайт данных.
За секунду процессор зашифрует 100Мбайт данных.
Вы уверены, что 1 команда выполняется за 1 такт?
Это совсем не обязательно. Главное процессор работает с информацией синхронно, а мощность ЭМИ и акустического определяется только количеством ключей переключающихся одновременно (и конечно параметрами ключа).
при этом количество транзисторов в Core I7 больше миллиарда. Возможно столько же в чипе современной видеокарты. И логика переключения этих всех транзисторов широкой публике не известна.
Логика публике неизвестна, но работа всех узлов синхронизируется из одного источника. И этого достаточно чтобы зарегистрировать явление.
Одно из его проявлений это разогрев элементов, которые вроде по природе своей не должны греться (конденсаторы).
Другое электромагнитное излучение которое создает широкополосные помехи, что тоже известно.
Третье привел в своей статье Ади Шамир.
Все это не только показывает возможность генерации процессором помех, но и подтверждает достаточно большую их мощность. И чем больше мощность — тем проще получить желаемый «наблюдателю» результат.
Одно из его проявлений это разогрев элементов, которые вроде по природе своей не должны греться (конденсаторы).
Другое электромагнитное излучение которое создает широкополосные помехи, что тоже известно.
Третье привел в своей статье Ади Шамир.
Все это не только показывает возможность генерации процессором помех, но и подтверждает достаточно большую их мощность. И чем больше мощность — тем проще получить желаемый «наблюдателю» результат.
Меньше чем за такт.
Вообще Вы правы. Приведённые ссылки на исследования (и на посты тут в том числе) имеют место быть, но только как теоритические выкладки, на практике не реализуемые.
Почему? Ведь есть конкретные указания на положительные результаты извлечения ключей. Но извлечь информацию (кроме ключей шифрования) проблема достаточно сложная и скорее пока теоретическая.
Изначально, меня этот вопрос интересует больше с точки зрения качественной фильтрации генерируемых процессором помех, снижения уровня ЭМИ и саморазогрева ими процессора и конечно увеличения тактовой частоты процессора.
Изначально, меня этот вопрос интересует больше с точки зрения качественной фильтрации генерируемых процессором помех, снижения уровня ЭМИ и саморазогрева ими процессора и конечно увеличения тактовой частоты процессора.
а есть указания, что кто-то смог повторить эти эксперименты с извлечением ключа?
А то может это эксперименты вроде тех, что Петрик ставит?
А то может это эксперименты вроде тех, что Петрик ставит?
pdf статья это публикация от одного из авторов алгоритма шифрования, а совсем не Петрика
И кто сказал, что автор алгоритма шифрования хорошо или даже достаточно разбирается в (микро-) электронике?
Он эту возможность обнаружил практически и зарегистрировал. Ну а автору как раз важно чтобы ключ был устойчивый.
Я регистрировал изменение характера помехи в зависимости от выполняемых процессором операций и достаточно большую ее мощность. Поэтому данная работа не является для меня неожиданной и только подтверждает мои результаты.
Я регистрировал изменение характера помехи в зависимости от выполняемых процессором операций и достаточно большую ее мощность. Поэтому данная работа не является для меня неожиданной и только подтверждает мои результаты.
В том то и дело, что «пока теоритическая». Я и не отрицаю — всё это реально, но просто на практике не применишь. Я с детства электроникой увлекаюсь, и представляю, как это выглядит «изнутри». Даже тот нюанс взять, что с момента выхода статьи уже алгоритмы переделали :)
А если целый час крутить эту же процедуру шифрования и каждый раз все с одним и тем же набором данных и ключом?
Конечно, если постоянно шифровать белый шум то ключ никогда в жизни таким методом не определишь.
Не так давно, были осциллографы со скромными параметрами(частота выборок что-то вроде 10М/сек) позволяющие рассматривать сигналы с частотами порядка гигагерц. Да собственно, это возможно и с 10Квыб/сек только времени нужно больше. Как они это делали? Примерно то же самое происходит и в данном случае, только куда сложнее.
Конечно, если постоянно шифровать белый шум то ключ никогда в жизни таким методом не определишь.
Не так давно, были осциллографы со скромными параметрами(частота выборок что-то вроде 10М/сек) позволяющие рассматривать сигналы с частотами порядка гигагерц. Да собственно, это возможно и с 10Квыб/сек только времени нужно больше. Как они это делали? Примерно то же самое происходит и в данном случае, только куда сложнее.
Описанный в статье анализ выполнялся спектроанализатором.
От продолжительности процедуры дешифровка ключа не зависит.
Когда шифруется белый шум то процессор обрабатывает два исходных сигнала: белый шум и ключ. Поэтому ключ можно извлечь.
Извлечение происходит не из результирующего сигнала, а из исходного.
От продолжительности процедуры дешифровка ключа не зависит.
Когда шифруется белый шум то процессор обрабатывает два исходных сигнала: белый шум и ключ. Поэтому ключ можно извлечь.
Извлечение происходит не из результирующего сигнала, а из исходного.
То ничего не получите. Так как у вас каждый раз разная картинка будет — по-разному заполняется кэш и по-разному отрабатывает суперскалярное исполнение и переименование регистров.Хоть прямо на цепи питания садитесь и оттуда сигнал пишите — всё равно на современных процессорах в реальных условиях ничего не получится выделить осмысленного. Разве что по патерну работы кэша сможете установить сам факт что работы алгоритма шифрования.
Есть весьма обоснованное мнение, что суммарный спектр там будет даже не 1 ГГц и не 10 ГГц, а более 1 ТГц. Т.е. оно вообще излучаться ни в каком виде не будет — сразу в тепло будет переходить.
Есть весьма обоснованное мнение, что суммарный спектр там будет даже не 1 ГГц и не 10 ГГц, а более 1 ТГц. Т.е. оно вообще излучаться ни в каком виде не будет — сразу в тепло будет переходить.
Быть может Вам покажется странным, но каждый узел процессора вносит свой вклад в создание обсуждаемой помехи. Наибольший вклад вносит ядро. Можете посмотреть термограмму процессора. Чем выше температура (выделяемая мощность) тем больше помеха. Разница по поверхности процессора может достигать 10 раз. Именно работу ядер и можно зарегистрировать на шине питания. Что и сделал (показал на примерах) Ади Шамир.
И это факт, который для меня еще раз подтвердил то, что я обнаружил в начале века.
Как это может произойти описано выше, а почему именно это так эффективно передается в акустическое поле можно разбираться. Одно из объяснений я дал.
И это факт, который для меня еще раз подтвердил то, что я обнаружил в начале века.
Как это может произойти описано выше, а почему именно это так эффективно передается в акустическое поле можно разбираться. Одно из объяснений я дал.
Верно. Плюс, у нас суперскалярные процессоры и они выполняют заметно больше, чем одну операцию за такт. Да ещё и каждый раз по-разному. Плюс, у нас колоссальный (по количеству транзисторов и потреблению) кэш параллельно и асинхронно работает. Да ещё и каждый раз по разному (он-то от предыстории зависит). И потребление этого кэша (как и всего процессора) зависит прежде всего от темпа обмена данными а не от содержания этих данных. Учёный плохо представляет, что именно он «слышит».
Посмотрел профиль AlexDS.
Вызывает уважение строка
Наверное, Вы один из старейших участников Хабра!
Интересно, есть ли статистика по старейшим (имеется в виду возраст)?
Вызывает уважение строка
Дата рождения: 16 января 1946
Наверное, Вы один из старейших участников Хабра!
Интересно, есть ли статистика по старейшим (имеется в виду возраст)?
Я вот уже который раз вижу подобные рассуждения и каждый раз одним из самых разумных аргументов становится разность частот работы процессора и частот ультразвука.
При этом будто забывается что в процессоре единовременно переключается не одна сотня транзисторов, даже если на нём запущен лишь один процесс, так что даже если (чисто теоретически) предположить что ультразвуком каким-то невообразимым образом будет сниматься вся информация с процессора, и даже путём длительного циклического повторения удастся как-то избавиться от шумов, то мы всё равно в итоге будем иметь не информацию о ключе, а лишь некий паттерн акустического шума, характерный для данных вычислений, но никак не информацию о самих вычислениях, это не реально попросту, чего бы там уважаемый Ади ни выкладывал на этот счёт, как хотите.
При этом будто забывается что в процессоре единовременно переключается не одна сотня транзисторов, даже если на нём запущен лишь один процесс, так что даже если (чисто теоретически) предположить что ультразвуком каким-то невообразимым образом будет сниматься вся информация с процессора, и даже путём длительного циклического повторения удастся как-то избавиться от шумов, то мы всё равно в итоге будем иметь не информацию о ключе, а лишь некий паттерн акустического шума, характерный для данных вычислений, но никак не информацию о самих вычислениях, это не реально попросту, чего бы там уважаемый Ади ни выкладывал на этот счёт, как хотите.
Почему бы нет? Каждый такт ультразвука несет в себе суммы операций и каждый такт — в новой фазе, таким образом что суммируются всегда разные участки одной повторяющейся операции, по этим данным если их достаточно много можно детализировать вплоть до отдельных операций потом остается только проанализировать поведение алгоритма и по нем вычислить исходные данные которые могут привести к такому поведению. Это подобно восстановлению расфокусированного изображения где по сути каждая точка изображения представляет собой суммы соседних. И как-то ведь восстанавливают.
Ну да, я выше уже повторял — реально, но не для практического применения. На практике паяльник в заднице окажется дешевле, нежели попытки что-то дешифровать по звуку.
Есть ситуации когда факт дешифровки не нужно придавать огласке, тогда паяльник — это будет очень грубый провал. Коды сменят, противник станет осторожней и толку от этого паяльника не будет.
Ну не получится так. Банальная камера проще будет, которая срисует с монитора какую-то информацию. Это сколько удачных совпадений должно быть, чтобы затея удалась: железо правильное, отсутствие внешних процессов, очень длительная работа алгоритма, наличие подслушивающего устройства в непосредственной близости, и т.д.
Ади Шамир пишет только о ключах шифрования и это реально из-за специфики алгоритма. А снятие информации вообще, это совсем другой процесс и пока об успехах не слышно.
Но есть еще один аспект — все пользователи могут находиться в достаточно сильном ультразвуковом акустическом поле (особенно производительных компьютеров и серверов). В серверных оно может превысить допустимые СНИП'ми величины.
Но есть еще один аспект — все пользователи могут находиться в достаточно сильном ультразвуковом акустическом поле (особенно производительных компьютеров и серверов). В серверных оно может превысить допустимые СНИП'ми величины.
Кстати да, но об этом мало кто задумывается. Я как-то пытался снять уровень шума в обычной обстановке (у себя в квартире), но проблема была с микрофоном, т.е. его не было подходящего. Обычные бытовые на частотах свыше 20 кГц просто уходят в шум, и непонятно, это реальный акустический шум, или шум микрофона, для того не предназначенного.
«Технический шум» имеет некоторую регулярность. И тут ответ на вопрос «что это» может дать только спектральный анализ (настоящий шум имеет спектр равномерный в широкой полосе частот).
А то что пока мало задумываются о воздействии ультразвука, то это так.
А ведь в быту и на работе все больше ВЧ (на частотах выше 20 КГц) источников питания. Это все «без трансформаторные» источники питания бытовой электроники, экономичные источники света, зарядки,…
А то что пока мало задумываются о воздействии ультразвука, то это так.
А ведь в быту и на работе все больше ВЧ (на частотах выше 20 КГц) источников питания. Это все «без трансформаторные» источники питания бытовой электроники, экономичные источники света, зарядки,…
«Каждый такт ультразвука несет в себе суммы операций и каждый такт — в новой фазе»
Вы же понимаете, что это лишь предположение.
Вы же понимаете, что это лишь предположение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Генерация акустического поля компьютером