Тема от Neekeetos (2012-06-13 16:38:00 отредактировано Neekeetos)

  • Neekeetos
  • Посетитель
  • Неактивен

Определение начального запуска функции, ключи Code и другие вопросы

Добрый день,

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

Также очень хочется отключить все что связано с шифрованием обмена между ключом и драйвером, поскольку эта штука очень сильно затормаживает работу программы, в частности я реализовал протокол обмена SSL между хранимым кодом и программой, и нету никакой необходимости чтото шифровать повторно.
Кроме того, я проверил скорость обмена данными с ключом, получается порядка 20килобайт в секунду (это код который ничего не делает, просто пустая функция)! Учитывая что алгоритм AES внутри ключа - исполняемого кода работает со скоростью больше мегабайта в секунду, непонятно куда уходит вся производительность. Так что если есть возможность ускорить все это , прошу указать на примерах как именно, примутся даже варианты не гарантирующие стабильной работы и/или не проверенные разработчиками.

Еще один вопрос связан с генератором случайных чисел встроенным в апи ключа, что является источником случайности в ключе?  Грубо говоря это реализация накапливающая энтропию или просто генератор бесконечной псевдослучайной последовательности? Какая вероятность того, что после сброса ключа этот генератор выдаст ту же последовательность   что и в прошлый раз?

И еще маленький вопрос -  сам ключ при сбросе как то инициализирует ОЗУ память кода пользователя? Тоесть, можно ли рассчитывать что память алгоритма будет забита при сбросе нулями например?


PS вот картинка иллюстрирующая тормоза : http://neekeetos.embedders.org/transfer.jpg,
вертикальная шкала это задержка отклика( в милисекундах) брелка с пустой функцией, горизонтальная - размер буфера приема в байтах, в названии линий цифра возле W означает размер буфера передачи. Это картинка с ноутбука с процессором Core2duo 1,6Ghz, чуть быстрее работает на рабочем компьютере, примерно пропорционально частоте процессора, те в ~2 раза. На ноутбуке если пересчитать скорость передачи выходит 12кб/с максимум, на компьютере порядка 25кб/с

Ответ от AndreyStepin

  • AndreyStepin
  • Техническая поддержка
  • Неактивен

Re: Определение начального запуска функции, ключи Code и другие вопросы

Neekeetos пишет:

Добрый день,

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

Также очень хочется отключить все что связано с шифрованием обмена между ключом и драйвером, поскольку эта штука очень сильно затормаживает работу программы, в частности я реализовал протокол обмена SSL между хранимым кодом и программой, и нету никакой необходимости чтото шифровать повторно.
Кроме того, я проверил скорость обмена данными с ключом, получается порядка 20килобайт в секунду (это код который ничего не делает, просто пустая функция)! Учитывая что алгоритм AES внутри ключа - исполняемого кода работает со скоростью больше мегабайта в секунду, непонятно куда уходит вся производительность. Так что если есть возможность ускорить все это , прошу указать на примерах как именно, примутся даже варианты не гарантирующие стабильной работы и/или не проверенные разработчиками.

Еще один вопрос связан с генератором случайных чисел встроенным в апи ключа, что является источником случайности в ключе?  Грубо говоря это реализация накапливающая энтропию или просто генератор бесконечной псевдослучайной последовательности? Какая вероятность того, что после сброса ключа этот генератор выдаст ту же последовательность   что и в прошлый раз?

И еще маленький вопрос -  сам ключ при сбросе как то инициализирует ОЗУ память кода пользователя? Тоесть, можно ли рассчитывать что память алгоритма будет забита при сбросе нулями например?


PS вот картинка иллюстрирующая тормоза : http://neekeetos.embedders.org/transfer.jpg,
вертикальная шкала это задержка отклика( в милисекундах) брелка с пустой функцией, горизонтальная - размер буфера приема в байтах, в названии линий цифра возле W означает размер буфера передачи. Это картинка с ноутбука с процессором Core2duo 1,6Ghz, чуть быстрее работает на рабочем компьютере, примерно пропорционально частоте процессора, те в ~2 раза. На ноутбуке если пересчитать скорость передачи выходит 12кб/с максимум, на компьютере порядка 25кб/с


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

1. Легальная возможность отслеживания запусков исполняемого кода это NO_INIT переменные. По умолчанию RAM обнуляется при перевтыкании ключа и между вызовами загружаемого кода. Если вы объявите переменную как NO_INIT то она будет изменяться только при перевтыкании ключа (в остальное время ее контролируете Вы), соответственно это можно будет отслеживать.

2. Мы рассматриваем такую возможность. При этом функционал ключа будет сведен к нешированным вызовам GrdCodeRun.

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

3. Генератор случайных чисел в ключ является криптостойким, накапливает энтропию и обладает очень и очень достойными характеристиками. В нашей компании работает ряд специалистов по криптографии, плюс мы сотрудничаем в этом вопросе с весьма известными "звездами" да и простые тестировщики у нас зачастую имеют техническое образование в области криптографии. Источников случайности в ключе несколько, в том числе генератор частоты микропроцессора тикающий с момента подачи питания с частотой больше 100 Мгц. Получить ту же последовательность после сброса ключа практически нереально.

4. На нули в ОЗУ вашего кода рассчитывать не стоит. Если например используется NO_INIT переменная для отслеживание подключений ключа и первых вызовов лучше там использовать осмысленное значение и проверять его не на обнуление а в принципе на изменение.

Касательно производительности: не только на стороне ключа могуть быть узкие места, но и на стороне защищенного псевдокодом Guardant API. На практике именно комбинация факторов влияют на скорость обмена. В текущем поколении ключей нужно приспособиться к имеющейся скорости.