The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

SQUIP - атака на процессоры AMD, приводящая к утечке данных по сторонним каналам, opennews (??), 12-Авг-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


84. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  –2 +/–
Сообщение от Аноним (-), 13-Авг-22, 15:23 
> разбавленный небольшими рандомными

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

double gauss_random(double mean, double variance) {
    double a = drand48(), b = drand48();
    return sqrt(-2 * log(a)) * cos(2 * M_PI * b);
}

double add_noise(double secret, double variance) {
    return secret + gauss_random(0, variance);
}

int main() {
#define LEN 4
    double secrets[LEN] = {0.42, -0.15, 0.18, 0.99}; // впиши сюда любые числа в диапазоне -1..1;
    // lets take N samples of secrets with added noise
    int N = 100;
    double sum[LEN] = { 0.0 };
    for(int i = 0; i < N; i ++) {
        for(int j = 0; j < LEN; j++) {
            // Notice this: noise variance is larger than a signal by an order of magnitude
            sum[j] += add_noise(secrets[j], 10);
        }
    }
    double rebuilt_secrets[LEN];
    for(int i = 0; i < LEN; i++) {
         rebuilt_secrets[i] = sum[i] / N;
    }
    // выведи здесь красиво табличкой secrets, rebuilt_secrets и разницу между ними
}

Попробуй поменять N и посмотреть как при увеличении N растёт точность восстановления secret'а. Попробуй например выставить N=500 или 1000. Твой случайный шум -- это помеха, которая конечно же мешает атакующему, но не отменяет возможность атаки. Как мёртвому припарки.

Если твоя хомячья сущность требует комментировать разговоры умных дядей и сходу предлагать простое решение, которое конечно же всех спасёт, и о котором умные дяди почему-то молчат, то тебе нужен не случайный шум, а одно из этого:

1. надо отменить мораторий на смертную казнь (универсальный вариант, работает всегда)
2. задницу подрастающим поколениям драть, как нам драли (этот похуже, но как правило работает)
3. надо запретить шедулеру шедулить разные процессы на одно ядро.

Но с 3 надо быть осторожнее. Любое отклонение от классических 1 и 2 требует осторожности. Это не так просто как кажется, потому что у шедулера нет времени пускать слюни и думать что и куда шедулить, да ещё и один новый эдж-кейс обрабатывать, когда есть свободные логические процессоры, есть простаивающие процессы готовые их утилизировать, но надо всё оставить как есть. Теоретически можно отбрыкаться от излишне умных, аппелируя к теоретической возможности придумать какой-нибудь резкий алгоритм, который так сделает. Но несмотря на недостатки у 3 есть бонус: твоя _целевая_ аудитория не поймёт о чём речь.

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

85. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  +/–
Сообщение от Онаним (?), 13-Авг-22, 15:34 
Ты путаешь тёплое с мягким.
Если у тебя уровень шума начинает превышать уровень полезного сигнала - всё, ничего ты уже не восстановишь, если не используешь шумоспецифичный фильтр. Который в случае рандома с примесью допустим хардварной энтропии не вырисовывается.
Ответить | Правка | Наверх | Cообщить модератору

99. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  +/–
Сообщение от Аноним (-), 13-Авг-22, 17:46 
> Если у тебя уровень шума начинает превышать уровень полезного сигнала

В моём примере превышает, и это не мешает.

> шумоспецифичный фильтр

Я намеренно генерацию рандома с нормальным распределением выделил в отдельную функцию. Попробуй воткнуть туда что-нибудь другое. Единственное усложнение, с которым тебе придётся столкнуться, это вычисление среднего значения шума. То есть такого m, что если x_n рандомное число, то \sum (x_n-m)  будет сходиться по вероятности к нулю, при n стремящимся к бесконечности.

> Который в случае рандома с примесью допустим хардварной энтропии не вырисовывается.

Прекрати поклоняться ложным идолам. Рандом -- не Бог, он не всемогущ. Он подчиняется статистическим закономерностям, типа закона больших чисел.

Ответить | Правка | Наверх | Cообщить модератору

87. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  +/–
Сообщение от Онаним (?), 13-Авг-22, 15:39 
И заметь, что ты работаешь не с изменённым исходным сигналом, а пытаешься восстановить сигнал по косвенным факторам, что в корне отличается от приведённого тобой примера, где сигнал модулирован.
Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

102. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  +2 +/–
Сообщение от Аноним (102), 13-Авг-22, 19:07 
И что математический аппарат то и там и там одинаковый.
Ответить | Правка | Наверх | Cообщить модератору

106. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  +/–
Сообщение от Онаним (?), 13-Авг-22, 21:07 
Угу. Только потребность в N различается на порядок порядков, а так ничего.
Ответить | Правка | Наверх | Cообщить модератору

90. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  +/–
Сообщение от Онаним (?), 13-Авг-22, 15:54 
Ну и предлагаю подумать вот на какую тему: с фига ли эти "эксплоиты" работают с 50500 раза, и только в лабораторных условиях, без стороннего шума, если всё так легко восстанавливается усреднением? А вот с того фига так и работает, что малейший лишний шум, и всё.
Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

91. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  +/–
Сообщение от Онаним (?), 13-Авг-22, 15:56 
И да, я не заметил, но с хера ли там шум аж строгого гауссового распределения будет?
Короче опять какие-то далёкие от реальности отмашки.
Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

92. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  +/–
Сообщение от Онаним (?), 13-Авг-22, 16:01 
Чёт меня реально подгорело с этого маразма.
Гауссово распределение тем и хорошо, что оно сферическое в вакууме, и на каждый +x найдётся -x, соответственно чем больше N, тем больше шанс полной компенсации и меньше остаток.
В реальном же аппаратном шуме ты всегда получишь некоторый офсет, который в случае попытки замерить не известных характеристик сигнал тебе компенсировать абсолютно нечем. И потенциальный офсет замерить тоже нечем.
Впрочем, даже если это откинуть - при превышающем уровень сигнала шуме тебе надо будет огроменные N, чтобы этот шум компенсировать, и все эксплоиты потребуют огромного времени для получения более-менее достоверного байта информации, чего уже вполне достаточно.
Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

100. "SQUIP - атака на процессоры AMD, приводящая к утечке данных ..."  +/–
Сообщение от Аноним (-), 13-Авг-22, 17:55 
> Чёт меня реально подгорело с этого маразма.

Я тоже хотел это сказать, но ты раньше успел.

> при превышающем уровень сигнала шуме тебе надо будет огроменные N, чтобы этот шум компенсировать

Да, это практическая проблема. Но, во-первых, у обороняющегося от атак тоже будут огромные практические проблемы сделать шум достаточно большим -- он совершенно не хочет, например, варьировать частоту проца в два раза (процентов на 10 может и ок, но не в 2 раза), и он совешенно не хочет делать таймер неюзабельным настолько, что мультимедиа приложения пойдут лесом, или что профайлеры станут бесполезными. Во-вторых, разница во времени выполнения разных ветвей измеряемого алгоритма может исчисляться хоть часами -- откуда ты знаешь? Ты можешь как-то ограничить это время и сказать, что эта разница будет не больше \delta, указав конкретное значение этой \delta?

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

Зашумлять сигнал -- это усложнять жизнь атакующему. Атака остаётся теоретически возможной, и про реальную систему во всей её сложности ты никогда не сможешь доказать, что она невозможна практически. Fail.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру