Тестирование M2M и Consumer RSP за пределами спецификаций

[Carding 4 Carders]

Почему нам нужно тестировать объекты M2M и Consumer RSP за пределами спецификаций? Зачем это делать, ведь это может потребовать дополнительных усилий? Давайте будем честными, никто не любит тратить много средств на свои потребности в тестировании, а бюджет зачастую бывает весьма ограниченным.

Необходимость выполнить тестирование на совместимость, чтобы определить, действительно ли eUICC поставщика X будет работать с SM-SR поставщика Y в M2M или SM-DP + поставщика Z гарантирует, что eUICC и Subscription Manager через устройство обеспечат необходимое взаимодействие с клиентами. Вот почему мы тестируем, но действительно ли нам нужно выходить за рамки текущего набора тестов, определенных соответствующими отраслевыми органами? Это происходит по целому ряду причин. В настоящее время отсутствует полное тестовое покрытие всех сущностей, а некоторые существующие области не полностью рассмотрены. Речь идет о сочетании факторов; оборудование, программное обеспечение, сеть, eUICC, Subscription Manager и устройство, которые являются взаимозаменяемыми и во многих случаях динамически переключаемыми.

В течение следующего месяца я проанализирую различные проблемы тестирования, связанные с eUICC, Subscription Manager и устройством, чтобы определить и объяснить, где нам нужно тестировать объекты M2M и Consumer RSP за пределами спецификаций.

В частности, мы подробно рассмотрим функциональное тестирование, где это применимо, тестирование профиля, тестирование логической безопасности и, наконец, тестирование физической безопасности, которое выполняется в отраслях M2M и Consumer RSP.

Определение среды тестирования M2M и Consumer RSP

Чтобы определить, что можно и что нельзя тестировать в домене M2M и Consumer RSP, нам сначала нужно взглянуть на две разные архитектуры для M2M и Consumer RSP, чтобы идентифицировать разные объекты в каждой архитектуре.

В этом блоге я не буду описывать подробные функциональные различия в различных архитектурах, но я рассмотрю тот факт, что интерфейсы Embedded SIM (ES) в обеих архитектурах необходимо тестировать на предмет объектов, которые входят в область действия.

Обе архитектуры имеют одинаковые объекты; Эмитенты сертификатов (CI), производители eUICC (EUM), eUICC и MNO или организации-операторы (которые фактически являются одним и тем же лицом). Однако основные различия в архитектурах связаны с «выталкивающей» природой M2M по сравнению с «выталкивающей» природой Consumer RSP. Итак, на стороне сервера у нас есть диспетчер подписки для предоставления данных (SM-DP) и диспетчер подписки для безопасной маршрутизации (SM-SR) для M2M. Затем на стороне потребителя у нас есть диспетчер подписок для предоставления данных Plus (SM-DP +) и диспетчер подписки для службы обнаружения (следует учитывать SM-DS. Плюс потребитель представляет конечного пользователя и помощника по локальному профилю (LPA), который конечный пользователь взаимодействует с, чтобы «тянуть» профили по запросу.

Вы также можете видеть, что некоторые из этих интерфейсов выходят за рамки основных спецификаций GSMA. Поэтому, используя эти знания, мы можем определить список объектов, которые находятся «в» и «вне области» для тестирования, что позволяет нам установить базовый уровень, чтобы определить, где нам может потребоваться тестирование помимо текущих спецификаций.

Тестируемые объекты - что выходит за рамки?

Давайте начнем сначала с рассмотрения сущностей, которые «выходят за рамки» тестирования? CI, EUM и MNO или оператор являются общими как для M2M, так и для Consumer RSP, поэтому все они действительно «выходят за рамки». Хотя фактически тестируется интерфейс ES1 между EUM и SM-SR, рассматривается только сторона SM-SR.

Оператор в Consumer RSP должен был входить в сферу действия, но существует так много различных реализаций серверной части MNO, что было трудно заставить MNO прийти к соглашению о том, будут ли они на самом деле поддерживать интерфейс ES2 + с SM-DP +. Тогда помощник по локальному профилю в eUICC (LPAe) не реализован ни на каких существующих eUICC и может никогда не быть реализован. Наконец, конечный пользователь явно выходит за рамки, поскольку мы не можем протестировать физическое лицо. Итак, теперь мы определили список объектов в обеих архитектурах, которые «выходят за рамки».

Тестируемые объекты - что входит в область действия?​

После исключения сущностей, которые не входят в область видимости, теперь намного проще определить, какие сущности входят в область проверки. Между M2M и Consumer RSP есть очевидное сходство. Необходимо протестировать как eUICC, так и менеджеры подписок, хотя сами сущности Subscription Manager названы по-разному и выполняют несколько разные роли и задачи между M2M и Consumer RSP. SM-SR требуется для поиска eUICC и управления профилями в M2M, но в Consumer RSP ответственность несет конечный пользователь, поэтому нет необходимости определять местонахождение eUICC, и SM-DP + начинает выполнять некоторые другие действия, которые SM- SR сделал - отсюда и знак "+". SM-DP и SM-DP + делают много одинаковых вещей, например, хранят профили, шифруют их и загружают, но Consumer RSP вводит SM-DS, который облегчает «проталкивание» профиля от Оператора для устройств, которые предварительно не настроены для их сети. Наконец, Consumer RSP добавляет устройство или телефон вместе со своим пользовательским интерфейсом управления локальным профилем, Local Profile Assistant (LPAd), где «d» в данном случае означает устройство.

Это означает, что теперь у нас есть список объектов, которые «находятся в области тестирования». У нас есть eUICC и диспетчер подписок как для M2M, так и для Consumer, а также Device / LPAd только для Consumer RSP.

Следующая неделя
На следующей неделе мы сосредоточимся на всех вопросах тестирования, связанных с eUICC. Так что, пожалуйста, присоединяйтесь ко мне для более глубокого анализа погружений.

Автор Иэн Максвелл.

 

[Carding 4 Carders]

Диспетчер подписки​

Добро пожаловать в последний выпуск этого блога о тестировании объектов M2M и Consumer RSP, выходящих за рамки спецификаций. На прошлой неделе мы рассмотрели тестирование устройства для доменов M2M и Consumer RSP. Поэтому на этой неделе я сконцентрируюсь на тестировании Менеджера подписки.

Тестирование менеджера подписки
Теперь давайте сконцентрируемся на Менеджере подписки, рассмотрев, что тестируется, а также любые проблемы и проблемы, связанные с тестированием различных типов Менеджеров подписки, чтобы определить, нужно ли нам проводить тестирование, выходящее за рамки спецификаций, а также как это сделать на практике. В следующей таблице обобщены объемы тестирования M2M и Consumer RSP Subscription Manager, и вы можете видеть, что требуется как функциональное, так и физическое тестирование операционной безопасности.

Таблица 1: Обзор тестирования диспетчера подписки

Как уже указывалось в первом блоге этой серии, и M2M, и Consumer RSP имеют два разных типа менеджеров подписок:

• M2M имеет диспетчер подписки для предоставления данных (SM-DP) и диспетчер подписки для безопасной маршрутизации (SM-SR).
• Потребитель имеет диспетчер подписки для Data Provisioning Plus (SM-DP +) и диспетчер подписки для службы обнаружения (SM-DS).

В M2M для тестирования как SM-DP, так и SM-SR в настоящее время нет органа сертификации, ответственного за процесс сертификации, но спецификация тестирования SGP.11 действительно обеспечивает полное покрытие функционального тестирования для обоих типов диспетчера подписки. Затем физическая безопасность M2M обеспечивается посредством аудита GSMA SAS с привлечением сторонних аудиторов для предоставления сертификата SAS-Subscription Manager (SAS-SM) в соответствии с документами безопасности GSMA FS.08, FS.09 и FS.10.
Опять же, в Consumer RSP для тестирования SM-DP + и SM-DS в настоящее время нет органа сертификации, ответственного за процесс сертификации, но спецификация тестирования SGP.23 действительно обеспечивает полное покрытие функционального тестирования для обоих типов диспетчера подписки. Затем физическая безопасность Consumer RSP снова предоставляется с помощью того же аудита GSMA SAS, что и для M2M.

Сертификация менеджера подписки
Каждая из выполненных отдельных тестовых областей Subscription Manager объединяется вместе, чтобы создать общий процесс соответствия продукта Subscription Manager, необходимый GSMA для входа Менеджера подписки в M2M или экосистему Consumer RSP.

Рисунок 1: Обзор сертификации диспетчера подписки

Сначала выполняется функциональное тестирование, но на самом деле это всего лишь «самотестирование», поскольку GSMA не согласовала орган по сертификации, ответственный за функциональное тестирование. Затем физическая или операционная безопасность выполняется в виде аудита SAS-SM в центре обработки данных поставщика Subscription Manager. Затем поставщик Менеджера подписки отправляет все результаты проведенного тестирования и аудита. Затем GSMA выполнит проверку доказательств, чтобы проанализировать достоверность результатов. Если проверка доказательств прошла успешно, GSMA CI затем выдаст и подпишет сертификат диспетчера подписки для аутентификации и шифрования профиля поставщику диспетчера подписки.

Тестирование диспетчера подписок: вопросы и проблемы​

Прежде всего, рассмотрим вопросы тестирования Subscription Manager, связанные с процессом сертификации.

Проблемы с сертификацией
Пока GSMA не определила сертификационный орган, способный и согласный выполнять сертификацию Subscription Manager для M2M или Consumer RSP, хотя GSMA обратилась к GlobalPlatform и GCF. Процессы GlobalPlatform требуют, чтобы тестируемый объект полностью находился в тестовой лаборатории во время квалификации, но поставщики Subscription Manager не смогли выполнить это требование, поэтому, к сожалению, GlobalPlatform здесь не выглядит жизнеспособным вариантом. GCF запросил дополнительное время для рассмотрения масштабов и последствий, связанных с этой задачей. Таким образом, это отсутствие сертификации может привести к будущим проблемам совместимости, и все еще продолжаются дебаты относительно области действия сертификации Subscription Manager, например, Являются ли функциональные возможности RSP + ОС Subscription Manager + оборудование сертификатом Subscription Manager? Что ж, хотя это все еще обсуждается, в рамках GSMA RSP-CERT, вероятно, будет достигнут консенсус, согласно которому функциональность RSP будет сертифицирована независимо от ОС Subscription Manager и оборудования. Надеюсь, это поможет GSMA в поисках ответственного органа по сертификации.

Теперь мы переходим к рассмотрению любых проблем с тестированием Менеджера подписки или проблем, вызванных техническими деталями.

Технические неисправности
В этом случае интерфейс ES2 + в Consumer RSP все еще выходит за рамки SGP.23 v1.2, что по-прежнему будет вызывать проблемы совместимости между операторами и поставщиками SM-DP +. Хотя ES2 + будет окончательно согласован в SGP.22 v3.0, который будет выпущен позже в этом году, после этого SGP.23 v2.0 будет обновлен для тестирования этого интерфейса между Оператором и SM-DP +. Другие проблемы тестирования в SGP.23, вызванные несогласованными формулировками в SGP.22, где необязательное использование значков, типов значков и т. Д. По сравнению с обязательной поддержкой уведомлений, profileOwner, правил политики в метаданных профиля вызывало несколько различных интерпретаций поставщиками Менеджера подписки.
В M2M также были обнаружены проблемы для процесса изменения SM-SR, которые были решены в недавнем обновлении SGP.11 v3.2 в середине 2017 года.

Инструменты тестирования Subscription Manager - решение проблем
Чтобы решить эти проблемы и в целом выполнить необходимое тестирование M2M Subscription Manager, UL предоставляет 2 инструмента тестирования. Наборы тестов UL SGP.11 SM-DP и UL SGP.11 SM-SR Test Suite предлагают функциональное тестирование по SGP.11 для SM-DP и SM-SR.

Рисунок 2: Наборы тестов UL M2M Subscription Manager

Эти инструменты могут использоваться только для целей «самотестирования», поскольку GSMA не удалось найти орган по сертификации, который возьмет на себя ответственность за процесс сертификации Менеджера подписки.

Розовая область в каждом из инструментов - это часть архитектуры, которую инструмент моделирует для выполнения тестирования. Таким образом, для SM-DP интерфейсы ES2, ES3 и ES8 являются активными тестируемыми интерфейсами Subscription Manager. Затем для SM-SR интерфейсы ES1, ES3, ES4, ES5, ES7 и ES8 являются активными тестируемыми интерфейсами Subscription Manager.

Затем, чтобы решить эти проблемы и в целом выполнить необходимое тестирование Consumer RSP Subscription Manager, UL предоставляет 2 инструмента тестирования. «UL SGP.23 SM-DP + Test Suite» и «UL SGP.23 SM-DS Test Suite» предлагают функциональное тестирование по SGP.23 для SM-DP + и SM-DS.

Рисунок 3: Наборы тестов UL Consumer Subscription Manager

Как упоминалось ранее, эти инструменты могут использоваться только для целей «самотестирования», поскольку GSMA еще не удалось найти орган по сертификации, который возьмет на себя ответственность за процесс сертификации Менеджера подписки.
Розовая область в каждом из инструментов - это часть архитектуры, которую инструмент моделирует для выполнения тестирования. Таким образом, для SM-DP + интерфейсы ES8 +, ES9 +, ES11 и ES12 являются активными тестируемыми интерфейсами Subscription Manager. Обратите внимание, что ES2 + по-прежнему выходит за рамки. Затем для SM-DS интерфейсы ES11, ES12 и ES15 являются активными тестируемыми интерфейсами Subscription Manager.

Служба аудита менеджера подписки - решение проблем
Физическая безопасность, предлагаемая GSMA SAS-SM, была принята менеджером по подписке во всем мире и предлагает более чем адекватные меры безопасности.

В настоящее время UL не предлагает SAS-SM, поскольку GSMA выбрала предпочтительный набор аудиторов и не будет снова открывать тендерный процесс до 2022 года.

Вывод
Менеджеры по подписке должны полностью тестировать свои продукты на соответствие функциональному тестированию, определенному в SGP.11 для M2M и SGP.23 для Consumer, и иметь возможность продемонстрировать, что они выполнили это функциональное тестирование. Но процесс сертификации менеджера подписки для M2M и Consumer RSP основан на самосертификации самих менеджеров подписки, что по своей сути не является надежным подходом.

Не существует выбранного органа сертификации для управления процессом, и не представляется жизнеспособной альтернативы, по крайней мере, в долгосрочной перспективе, но UL полагает, что GSMA может потребовать в SGP.24 для Consumer RSP или эквивалентном документе SGP.24 процесса. от M2M, использование стороннего инструмента тестирования, который, несомненно, поможет улучшить процесс.

У менеджеров подписки есть много дополнительных функций, которые они могут поддерживать или не поддерживать, и ожидается, что многие поставщики менеджеров подписки предпочтут тестировать только те функции, которые им необходимы для данных клиентов. Поэтому рекомендуется, чтобы все клиенты поставщиков диспетчера подписки обращали особое внимание на то, какие дополнительные функции были протестированы диспетчером подписки, чтобы гарантировать, что они получат набор функций, который они ожидают как клиент.

Поэтому рекомендуется протестировать диспетчер подписки за пределами тестовых спецификаций SGP.11 и SGP.23 для выявления и решения любых возможных проблем взаимодействия, таких как процесс изменения SM-SR для M2M или потенциальные проблемы ES2 + для RSP потребителя соответственно.

 

[Carding 4 Carders]

Общая отладка и заключение​

Добро пожаловать в последнюю часть этой серии блогов о тестировании объектов M2M и Consumer RSP, выходящих за рамки спецификаций. За последние 4 недели мы подробно описали, как мы определили объем сущностей, которые «входят в объем», и тех, которые «выходят за рамки» тестирования в доменах M2M и Consumer RSP. Мы также специально рассмотрели тестирование сущностей, определенных как «входящие в область видимости»; eUICC, устройство и диспетчер подписок. В этом последнем блоге серии я расскажу об общих проблемах отладки, связанных с eUICC, устройством и диспетчером подписок, прежде чем мы проанализируем результаты в окончательном заключении.

Проблемы с отладкой
Давайте сконцентрируемся на задаче отладки любых потенциальных проблем или проблем, которые могут возникнуть во время тестирования любой из сущностей, которые мы ранее определили как «входящие в область действия».
Отладка большинства проблем и проблем часто зависит от возможности слежения за активными интерфейсами M2M или Consumer RSP. Но самая большая проблема с технологиями eSIM заключается в том, как физически шпионить за трафиком интерфейса M2M и Consumer RSP?
Диспетчер подписки или слежка на стороне сервера проблематичны, поскольку поставщики диспетчера подписки не захотят допускать сторонние инструменты в свои центры обработки данных. Затем на стороне устройства M2M и потребительские устройства могут иметь встроенные eUICC, что затрудняет слежку за трафиком интерфейса, поскольку физическое подключение зонда шпионского инструмента проблематично.
Кроме того, даже если вы преодолеете все физические непрактичности, даже если большая часть трафика процесса аутентификации может быть отслежена, весь трафик интерфейса содержимого профиля зашифрован, поэтому вам понадобятся PSK для M2M eUICC или связанный секретный ключ и сертификаты RSP потребителя.

UL Mobile Spy - решение проблем
Чтобы решить проблему отладки любых проблем, обнаруженных во время тестирования устройства, eUICC и, возможно, менеджеров подписок, UL предоставляет инструмент UL Mobile Spy. Он переводит и визуализирует обмен данными между устройствами или телефонами и UICC или eUICC на интерфейсе ISO 7816, а также любой бесконтактный или NFC-трафик на интерфейсе ISO14443 и SWP между UICC, CLF и бесконтактными считывателями.

Рисунок 1: Шпионское решение UL

Инструмент также поддерживает мощную функцию динамического дешифрования протоколов защищенного канала; SCP02, SCP03, SCP03t, SCP80 и SCP81, если у него есть PSK для M2M eUICC или секретный ключ и сертификаты RSP Потребителя.
Затем инструмент-шпион можно использовать в сочетании с любым набором тестов UL или инструментами тестирования, чтобы помочь в отладке любых проблем, которые инструмент тестирования может обнаружить в тестируемой сущности.

Вывод
За последний месяц мы узнали, что для гарантии взаимодействия и масштабируемости все компоненты и интерфейсы в доменах M2M и Consumer RSP должны быть полностью протестированы и сертифицированы. Давайте теперь рассмотрим каждую тестируемую сущность по очереди:

Тестирование eUICC
EUICC имеет довольно надежный M2M и скоро будет процесс сертификации Consumer RSP для функциональной, профильной, логической и физической безопасности. В настоящее время нет никакой острой необходимости в функциональном тестировании, выходящем за рамки спецификаций, если EUM может хотя бы продемонстрировать, что они выполнили это тестирование, но интересным дополнением может быть тестирование производительности BIP eUICC как части M2M и потребительского функционала. тестирование. Кроме того, GSMA и их члены MNO действительно могли бы улучшить процесс сертификации, если бы потребовали функциональное и профильное тестирование eUICC.

Когда дело доходит до логической безопасности, EUM отклоняют аудиты Common Criteria, которые GSMA проводит и пытается внедрить, поэтому GSMA должна решить эту проблему как можно скорее, поскольку любые нарушения безопасности будут весьма опасными. Поэтому UL рекомендует проявлять дополнительную осторожность во время логического тестирования безопасности, которое многие из EUM предоставляют в качестве самооценки, особенно потому, что они могут попытаться использовать и продемонстрировать эквивалентную безопасность с помощью других отраслевых аудитов, которые явно не нацелены на M2M или Потребительская архитектура и экосистема RSP. Но, по крайней мере, физическая безопасность, предлагаемая GSMA SAS-UP, была принята EUM во всем мире и предлагает более чем адекватные гарантии.

Тестирование устройства
Тестирование устройства применимо только для устройств Consumer RSP. GCF и PTCRB всегда сохраняли довольно сильные позиции в мире операторов мобильной связи и оператора мобильной связи, поэтому OEM-производителям пришлось полностью принять процессы сертификации этих двух проверяющих органов, чтобы гарантировать, что они могут предлагать свои телефоны своим клиентам MNO и MVNO. Таким образом, сначала может показаться, что тестирование устройств - это довольно здоровое состояние, но, поскольку оно использует только Wi-Fi, существует реальная необходимость в тестировании всех устройств OTA, хотя и не повторять весь спектр тестов, выполненных в SGP.23, а на наименьшее выполнение подмножества из них с точки зрения уверенности. Плюс дополнительный подход может заключаться в тестировании производительности BIP модема устройства M2M во время SGP. 11 функциональное тестирование, чтобы определить, существуют ли какие-либо сценарии, при которых поставщик услуг может оставить устройство без подключения к Интернету в течение неприемлемых периодов времени. Также возможно выполнение аналогичного типа тестирования на потребительских устройствах на интерфейсах ES10X во время функционального тестирования SGP.23.
Затем для устройств со съемными eUICC это рассматривается как необходимость выполнения дополнительных тестов на совместимость, чтобы в будущем убедиться в возможных проблемах взаимодействия. Но это тестирование никогда не может быть полностью всеобъемлющим, что приведет к неизвестному или неожиданному поведению.
Также рекомендуется, чтобы MNO и MVNO проводили приемочное тестирование пользователей устройств Consumer RSP через интерфейс ESeu, чтобы гарантировать, что желаемый уровень взаимодействия с пользователем достигается, если не согласованно, на всех устройствах, и в то же время защищать бренд MNO.

Тестирование менеджера подписки
Поскольку не существует назначенного органа сертификации для процесса сертификации Менеджера подписки для M2M и Consumer RSP, он полагается на самосертификацию самими Менеджерами подписки, что по своей сути не является надежным подходом. Поставщики менеджеров по подписке должны иметь возможность продемонстрировать, что они выполнили функциональное тестирование, определенное в SGP.11 для M2M и SGP.23 для Consumer, в отношении своих продуктов. Однако UL полагает, что GSMA может потребовать в SGP.24 для Consumer RSP или в эквивалентном документе SGP.24 от M2M использование стороннего инструмента тестирования, который, несомненно, поможет улучшить процесс. У менеджеров подписки также есть много дополнительных функций, которые они могут поддерживать или не поддерживать, и ожидается, что многие поставщики менеджеров подписки предпочтут тестировать только те функции, которые им необходимы для данных клиентов. Очевидно, что неразумно просить все диспетчеры подписок поддерживать все дополнительные функции, поэтому рекомендуется, чтобы все клиенты поставщиков диспетчера подписок обращали особое внимание на то, какие дополнительные функции были протестированы диспетчером подписки, чтобы гарантировать, что они получат эту функцию. установите то, что они как покупатели ожидают. Кроме того, рекомендуется протестировать диспетчер подписки за пределами тестовых спецификаций SGP.11 и SGP.23, чтобы помочь выявить и решить любые возможные проблемы технической совместимости, такие как проблемы, недавно решенные в процессе изменения SM-SR для M2M, или потенциальные проблемы ES2 +, вызванные тем, что этот интерфейс выходит за рамки SGP.23 для Потребителя соответственно.

Общая отладка
Отладка любых проблем, обнаруженных во время тестирования, может потребоваться с использованием шпионского инструмента, но физический доступ может оказаться затруднительным, плюс вам необходимо получить для этого секретные ключи eUICC, что может оказаться трудным для инженеров-тестировщиков. приобретать. Но если вам удастся получить физический доступ и доступ к необходимым ключам и сертификатам, использование мощного шпионского инструмента станет очень мощным инструментом, который поможет вам отладить все интерфейсы устройств eUICC. Возможность дополнить это сетевым шпионским инструментом на стороне Subscription Manager обеспечила бы отличные возможности отладки E2E, но ожидается, что доступ к центру обработки данных, где находится менеджер подписки, а также согласование точки доступа в их системе, будет заблокирован.

Последние мысли
Тогда становится ясно, что мир M2M и Consumer RSP все еще довольно незрел, и небольшое дополнительное тестирование здесь и там будет иметь большое значение для защиты ваших инвестиций в эти новые технологии для любого игрока в экосистеме. Кроме того, если у вас есть подходящие инструменты и даже шпионский инструмент, который поможет вам выполнить текущую работу, то дополнительное тестирование не будет таким дорогостоящим, как вы изначально опасались.