ключ как мост данных между триальной частью функционала и платными функциями: "Нет ключа - данные из основного блока просто не попали в коммерческую часть приложения. Удобно тем что нет никаких условий и сравнений.
Хороший подход и с идеей.
Только не забывайте о том что память ключа немного ограничена (я уткнулся в лимит).
Впрочем, когда ключи дойдут и начнете эксперементировать - готов про Code много чего рассказать (как его правильно готовить) :)
Аналитик пишет:А что произойдет в данном случае кроме потери данных?
К примеру мы пишем в ключ количество оставшихся запусков, таким макаром можно увеличить это значение :)
в моей реализации некритично, т.к. планировалось использовать ключ как мост данных между триальной частью функционала и платными функциями: "Нет ключа - данные из основного блока просто не попали в коммерческую часть приложения. Удобно тем что нет никаких условий и сравнений.
]]>А что произойдет в данном случае кроме потери данных?
К примеру мы пишем в ключ количество оставшихся запусков, таким макаром можно увеличить это значение :)
]]>В четвертых, есть еще конечно вариант с Guardant Code - ключ, конечно, немного дороговат, но там есть много приятностей, одной из которых является отсутствие лимита на 1 миллион перезаписей (ресурс гораздо выше, правда не во все области памяти). А другой приятностью, является то, что мы можем принимать данные из софтверного блэкбокса, реализуемого в приложении (к примеру закрытого виртальной машиной) и спокойно их расшифровывать непосредственно в ключе, где и принимать решение - как именно и где будем их хранить - во внешней FLASH или внутри защищенного блока (там тоже есть нюансы, но грубо как-то так).
Благодарю, Александр!
Уже заказал ключи Guardant Code они где-то в пути мне тоже они показались более удобными. Только вот нет примеров по ним...
Во вторых, может произойти потеря сессии, в случае, когда ключ изымут из порта перед попыткой записи.
А что произойдет в данном случае кроме потери данных?
]]>В самом простом приближении воспользуйтесь предлагаемой SDK криптографией с привязкой к ID ключа, а для рандомизации, GP счетчиком 0х6 оффсет UAM, который будет декрементировать при каждом обращении к "критическому участку кода".
Сами данные храните там где вам удобно.
В четвертых, есть еще конечно вариант с Guardant Code - ключ, конечно, немного дороговат, но там есть много приятностей, одной из которых является отсутствие лимита на 1 миллион перезаписей (ресурс гораздо выше, правда не во все области памяти). А другой приятностью, является то, что мы можем принимать данные из софтверного блэкбокса, реализуемого в приложении (к примеру закрытого виртальной машиной) и спокойно их расшифровывать непосредственно в ключе, где и принимать решение - как именно и где будем их хранить - во внешней FLASH или внутри защищенного блока (там тоже есть нюансы, но грубо как-то так).
В итоге - я бы посоветовал остановиться на промежуточном варианте решения (через доступные криптоапи из SDK), правда сам использую последний вариант, ибо он мне более удобен, с учетом почти 9 летнего варианта работы с промежуточным :)
]]>