Быстродействие различных версий библиотек из sdk

Добрый день, использую в программе статическую линковку с библиотекой guardant, компилятор gcc/mingw , при переходе на новую версию  sdk (6.1)  и библиотеки обнаружил существенное падение производительности. Подскажите пожалуйста в чем тут может быть дело и как  решить данный вопрос? 

PS  После такого провел детальные измерения для 3 версий библиотек 5.51, 6.0 и 6.1,  если принять время выполнения запроса на 6.0 за 100% то выходит следующая картина:
5.51  161%
6.0 100%
6.1 196%
На сайте для 6.1 указано следующее:
Новое программное обеспечение для сетевых ключей Guardant:

    Абсолютно новый сервер сетевых ключей;
    Новый уровень производительности и стабильности;

я так полагаю к функционированию обычных ключей это не относится?

Re: Быстродействие различных версий библиотек из sdk

Neekeetos пишет:

Добрый день, использую в программе статическую линковку с библиотекой guardant, компилятор gcc/mingw , при переходе на новую версию  sdk (6.1)  и библиотеки обнаружил существенное падение производительности. Подскажите пожалуйста в чем тут может быть дело и как  решить данный вопрос? 

PS  После такого провел детальные измерения для 3 версий библиотек 5.51, 6.0 и 6.1,  если принять время выполнения запроса на 6.0 за 100% то выходит следующая картина:
5.51  161%
6.0 100%
6.1 196%
На сайте для 6.1 указано следующее:
Новое программное обеспечение для сетевых ключей Guardant:

    Абсолютно новый сервер сетевых ключей;
    Новый уровень производительности и стабильности;

я так полагаю к функционированию обычных ключей это не относится?

Каждый раз при выходе новой версии Guardant API оно защищается новым экземпляром псевдокода. Этот псевдокод в силу уникальности своих характеристик для каждого факта защиты может несколько различаться по производительности. Более того, на разных операциях это отражается по разному. Из вашей статистики неясно, например, быстродействие какой именно функции вы измеряли. Если на какой то функции время исполнения выросло с 1 мс до 2 мс это некритичино в общем случае. Но если цифры 20 мс и 40 мс то с этим надо разбираться.

Если вы уточните какие функции мерялись, то мы обязательно проверим что к чему.

Касательно нового ПО для сетевых ключей: переписан был именно сервер и соответствующая часть Guardant API - переделан протокол общения с ключом по сети, введены новые принципы лицензирования. Сетевые ключи стали заметно быстрее, к локальным это вообще никак не относится.

Re: Быстродействие различных версий библиотек из sdk

AndreyStepin пишет:

Если вы уточните какие функции мерялись, то мы обязательно проверим что к чему.

GrdCodeRun вызывающая пустую функцию в ключе с буферами приема и передачи 1к байт. Вы не могли бы после измерения озвучить цифры, которые у Вас получились, в частности интересует задержка вызова и количество байт в секунду переданных с/на ключ. Я к сожалению не использую все функции апи, только лишь необходимые для поиска ключа, создания сессии и функцию запуска кода, но Вы могли бы замерить также и несколько других, например функции работы с защищенными ячейками и аппаратными алгоритмами. Думаю такая информация была бы всем интересна.

AndreyStepin пишет:

Касательно нового ПО для сетевых ключей: переписан был именно сервер и соответствующая часть Guardant API - переделан протокол общения с ключом по сети, введены новые принципы лицензирования. Сетевые ключи стали заметно быстрее, к локальным это вообще никак не относится.

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

Re: Быстродействие различных версий библиотек из sdk

Добрый день.
Я тоже столкнулся с низким быстродействием библиотеки (версия 6.2) при работе с ключом GuardantCode. Например, вызов пустой функции, загруженной в ключ, занимает больше 20 мс. И это на мощном процессоре (Core i7). Никакие данные через буфер в ключ не передаются. При работе в Linux ситуация ещё хуже.
Можно ли надеяться на улучшение в этом вопросе или отказаться от использования Guardant?

Александр.

Re: Быстродействие различных версий библиотек из sdk

Минимальное обращение к ключу это действительно 18-20 мс. Существуют определенные ограничения при обмене между ключом и компьютером, обусловленные скоростью ARM-процессора ключа, скоростью компьютера, спецификацией USB, задержками в стеке USB-драйверов, протоколом общения с ключом, шифрованием этого протокола и защитой клиентской части псевдокодом Guardant. Это все снижает скорость обмена, но повышает защищенность и сложность перехвата и анализа трафика с ключом.

В частности, USB-спецификация ограничивает частоту опроса ключа значением 1000 раз в секунду. Т.е. мы можем отправлять запрос в ключ не чаще одного раза в 1 мс. Даже пустой вызов GrdCodeRun с точки зрения протокола обмена это сложная операция, состоящая из серии запросов и ответов к ключу. Если снять с этой функции шифрование протокола и псевдокод то можно добиться понижения задержки с 20 мс до 15 мс, но ценой этого будет существенное падение защищенности.

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

Нужно искать баланс между размещением кода в ключ и зависимостью от него и качеством системы защиты. Собственно в этом есть некоторое искусство :)

Re: Быстродействие различных версий библиотек из sdk

Сейчас у нас в проекте работает смарт-карта через USB-картридер и там задержка получается порядка 4 мс, несмотря на то, что это включает ещё задержку между картой и ридером. Я надеялся, что у Guardant будет сопоставимая задержка и получится хорошая замена.
Если насчёт перехвата и анализа трафика, то для защиты, основанной на перенесенном в ключ коде, это (имхо) бессмысленно.  К тому же легче анализировать обращения к библиотеке GuardApi.