Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Кошелёк

Кошелёк Mobile Challenge итоги конкурса и подробный разбор решений командой разработки

18.12.2020 14:16:13 | Автор: admin

У нас было две платформы, 1 000 000 рублей призового фонда, 6 призовых мест, 26 тысяч строк кода, которые нужно прочитать и оценить, а также 20 страниц фидбеков, несколько критериев оценки, ящик Бадвайзера, пинта чистого эфира и 12 пузырьков успокоительного. Не то, чтобы всё это было категорически необходимо для проведения конкурса разработчиков, но если уж начал оценивать решения, то к делу надо подходить серьёзно.

Подводим итоги конкурса Кошелёк Mobile Challenge и в деталях разбираем решения участников.

Задание

Попробуйте передать ощущения физического кошелька в приложении Кошелёк и переосмыслить два экрана: главный экран со списком карт и экран с деталями карты.

Предложите техническую реализацию этих экранов и перехода между ними. Логика отображения, сортировка списка карт, UI/UX, анимации и все остальные нюансы остаются на ваше усмотрение.

Конкурс в цифрах

1 задание

2 платформы (iOS и Android)

1 000 000 рублей призового фонда

100 пользователей в телеграм-канале конкурса

1 месяц на разработку решения

13 участников

11 судей

6 призовых мест

Победители

iOS

1 место (250 000 рублей) Антон Спивак

2 место (150 000 рублей) Роберт Шагинян

3 место (100 000 рублей) Павел Протасов

Android

1 место (250 000 рублей) Андрей Эрдман

2 место (150 000 рублей) Виталий Кириллов

3 место (100 000 рублей) Георгий Ипполитов

Разбор решений

Все участники уже получили отзывы на решения со стороны продуктовой и технической команды и скоро получат в подарок наш мерч, а лучшие из них денежное вознаграждение и приглашение присоединиться к команде Кошелька.

Напомним основные критерии оценки:

  1. Чистота и расширяемость кода.

  2. Плавность, скорость и отзывчивость интерфейса.

  3. Стабильность работы.

  4. Процент поддерживаемых ОС и устройств.

Технические требования:

  1. Нативное iOS- или Android-приложение, без кросс-платформы.

  2. Для Android: поддержка 23+ API.

  3. Для iOS: поддержка iOS 11+.

Разбор iOS решений

Соответствие техническим требованиям

Все представленные решения нативные, написаны на Swift, что не может не радовать. У большей части минимальная поддерживаемая версия ОС 11, что дает дополнительные баллы при оценке. А кто-то, вероятно, просто забыл указать, так как в проектах мы не нашли использования специфичного для новых версий API. Xcode же при создании нового проекта любезно ставит минимальной ту версию, которая для текущего SDK самая свежая.

Типичные ошибки и рекомендации

Несоблюдение принципа DI (Dependency Inversion)

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

Нарушение принципа SR (Single Responsibility)

Это довольно холиварный принцип: не всегда очевидно, что считать единственной ответственностью, но встречались случаи, когда раздувание сущности дополнительной функциональностью затрудняет дальнейшее расширение. В таких случаях мы рекомендуем передекомпозировать/перепроектировать эту часть кода.

Создание лишних уровней абстракции

Каждый новый уровень увеличивает когнитивную сложность восприятия кода, поэтому выделение абстракции ради абстракции только ухудшает читабельность проекта. Самый часто встречающийся пример в iOS-приложениях использование протоколов с единственной реализацией в виде класса и структуры с именованием вида MyClassName и MyClassNameProtocol.

Рекомендуем не выделять протокол всегда, а только когда этого требует задача (задел на реализацию полиморфизма или сложность юнит-тестирования). В общем, мы за расширяемость (и уточнили это в критериях оценки), но не способом добавления протоколов к каждому классу и структуре в проекте.

Использование reference вместо value типов там, где в этом нет явной необходимости

Пример:

class RequestModel: Request {    var method: HTTPMethod = .get    var headers: [String : String]? = nil    var url: URL = URL(string: "https://textures.cardsmobile.ru")!    var parameters: [String : String]? = nil    var contentType: ContentTypeRequestEnum = .applicationURLEncoder}

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

Использование лишних 3rd party зависимостей

Многим разработчикам кажется, что библиотека Alamofire является стандартом индустрии для организации сетевого слоя. Она очевидно имеет ряд преимуществ и позволяет не изобретать велосипед каждый раз при работе с сетью в большом приложении. И все же, использовать Alamofire только для того, чтобы быстро написать AF.request(url).response { } выглядит необоснованным решением. В чем отличие от URLSession.shared.dataTask(with: url) { }.resume()? Кажется, что разницы никакой. При этом подключая такую большую библиотеку в своей проект, мы увеличиваем размер дистрибутива и потенциально затягиваем чужие баги. Хочется пошутить, перефразировав Билла Гейтса нативного URLSession должно хватить всем. Но как мы знаем, в любой шутке есть доля правды.

Неправильное сохранение контекстов в Core Data

Во время работы с несколькими контекстами (NSManagedObjectContext) при сохранении данных встречаются случаи последовательного вызова метода save() у контекстов. Оптимальнее подписываться на нотификацию NSManagedObjectContextDidSave и мержить данные с background контекста в главный view контекст. Опыт подсказывает, что сохранение через нотификации быстрее с точки зрения перформанса.

Рекомендуем для ознакомления книгу с описанием лучших практик использования Core Data.

Чрезмерное использование глобальных очередей DispatchQueue.global

В том числе из-за того, что очереди конкурентные, при частых вызовах метода async (загрузка картинки для каждой ячейки таблицы или коллекции), в какой-то момент работы программы можно обнаружить, что количество используемых тредов перевалило за несколько десятков, что снижает общую производительность приложения.

Не стесняйтесь создавать собственные очереди (желательно последовательные), чтобы избежать этой проблемы. За деталями рекомендуем обратиться к статье бывшего инженера Apple о советах по улучшению перформанса.

Использование background Quality Of Service (QoS)

Код в очереди с приоритетом background может при некоторых системных условиях не выполниться, что может повлечь за собой трудноуловимые баги (ведь кажется, редко бывает, что нам неважно, выполнится указанный код или нет). Лучше заменять на QoS utility. Подробности в треде.

Чрезмерная нагрузка главного потока задачами

Самые яркие примеры из предложенных решений загрузка из сети и ресайзинг картинок на главном потоке.

Такие операции требовательны к ресурсам, отсутствие плохой сети на больших по размеру картинках может сыграть злую шутку и скролл будет подлагивать на списках. Рекомендуем разгружать главный поток, а вот годная статья Image Resizing Techniques с сравнением различных техник ресайзинга изображений.

Игнорирование важных событий жизненного цикла приложения и UIViewController

Конкурсанты предложили логичную фичу при открытии штрихкода увеличивать яркость экрана, чтобы он считывался легче. Для этого можно управлять яркостью в методах viewWillAppear и viewWillDisappear (для того, чтобы вернуть яркость в исходное состояние). Но, как показывает практика, обычно пользователь после предъявления карты просто сворачивает приложение. В таком случае яркость останется на максимуме, и одна звезда в App Store вам обеспечена.

Рекомендуем не забывать про нотификации UIApplicationDidEnterBackgroundNotification и UIApplicationDidBecomeActiveNotification, которые сигнализируют о том, что приложение было свернуто и развернуто соответственно.

Отсутствие адаптивности под разные размеры экранов

Почти во всех проектах не было адаптации UI под мелкие и большие скрины. Поддержка дополнительного размера экрана только увеличит лояльность пользователей, поэтому рекомендуем проверять на разных девайсах и помнить про Safe Area.

Орфографические ошибки в коде

Частые ошибки затрудняют читабельность и ревью кода, снижает поиск нужных элементов по проекту. Понятно, что такие ошибки часто возникают из-за того, что замылился глаз или в состоянии потока быстро программируешь, пока не ускользнула мысль. Но всё же мы за код без ошибок (во всех их проявлениях), и поэтому рекомендуем включить проверку орфографии в Xcode с помощью Edit > Format > Spelling and Grammar > Check Spelling While Typing.

Проблемы с лейаутом констрейнов

В ситуациях, когда констрейны расставлены неверно, система не может однозначно их интерпретировать, чтобы понять финальный лейаут UI. Xcode помогает в этом и выбрасывает в консоль сообщения вида Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want.

Рекомендуем следить за этими сообщениями, а также ознакомиться со статьей Debugging Tricks and Tips.

Предупреждения (warnings) на этапе компиляции

Сюда могут относиться сообщения анализатора кода (swiftlint, если он у вас встроен в проект, встроенного анализатора об использовании deprecated методов и т.д.), обновление до рекомендуемых настроек проекта и т.д.

Правило простое: считаем каждый ворнинг техническим долгом проекта и стараемся свести их число к нулю. Стараемся не называть их наличие творческим беспорядком :)

Неиспользуемый и закомментированный код в проекте

Каждая неиспользуемая строка кода это и дополнительная работа для компилятора, и лишняя когнитивная нагрузка на разработчика, который изучает код проекта. Рекомендуем удалять такой код из проекта.

Магические константы

Как пример: выражение self.viewModel.objects().count%5 тяжело понять почему именно эти значения используются, особенно когда возвращаешься к коду через какое-то длительное время.

Как вариант, рекомендуем применить в этом месте метод рефакторинга Замена магического числа символьной константой. Развернутое описание этого и других методов можно найти в книге Рефакторинг. Улучшение существующего кода Мартина Фаулера.

Что понравилось с технической стороны

Архитектура презентационного слоя

В большей части решений логика представления отделена от бизнес-логики, навигация между экранами тоже изолирована, что позволяет легко расширять количество экранов без изменения существующих. Многие выделяют такие составляющие, как View, Interactor, Model и Builder для сборки сцены и экрана.

Наличие билдера плюс со стороны работы с DI (Dependency Injection).

В одном из решений работа с зависимостями организована с использованием Dependency Container, что позволяет упростить работу с ними.

Сокрытие использования конкретной библиотеки за оберткой

В нескольких решениях использовалась библиотека Kingfisher для подгрузки картинок, только в одном использование было спрятано за классом ImageLoader. Это позволяет не размазывать 3rd party зависимость по всему проекту.

Использование ключевого слова final в декларации класса, метода или свойства

По стандарту при его отсутствии у класса разрешается создавать класс-наследник от указанного класса или переопределять метод в дочернем классе в рамках текущего модуля. Наличие ключевого слова final поможет компилятору оптимизировать код и выжать немного перформанса за счет использования статической диспатчеризации вместо динамической. При включении Whole Module Optimization в большинстве случаев компилятор справится сам и проставит final. Но в ситуациях, когда методы или свойства наследуемого класса делаются видимыми, но необходимо запретить их переопределение, то final будет полезен. Подробности в блоге.

Что понравилось с продуктовой стороны

Идеи организации списка карточек

#1 Размер карточки увеличивается при скролле, при двойном нажатии появляется штрихкод

#2 Горизонтальный скрол, дополнительно переходить на детали не требуется, чтобы показать штрихкод

Наличие офлайн-режима и быстрый запуск при холодном старте

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

Поддержка тёмной темы

Apple и бОльшая часть пользователей всесторонне поддерживают наличие Dark Mode, поэтому плюсуем тем решениям, где была сделана поддержка.

Локализация

В некоторых решениях добавлена поддержка двух языков русского и английского.

Поиск

Фильтрация

#1 Возможность показывать только просроченные или действительные элементы

#2 Фильтрация по категориям

Разбор Android-решений

Соответствие техническим требованиям

Все присланные решения нативные и написаны с использованием Kotlin, минимально поддерживаемый системный API 23+ использовали все.

Типичные ошибки и рекомендации

Почти все решения были сделаны без группировки по категориям. Данных апи было достаточно для организации удобного UI. Отсутствовала сортировка drag&drop.

Нарушение принципа DI (Dependency Inversion), повсеместное использование паттерна Singleton

В одном из проектов CardsInteractor из domain-слоя обращается напрямую в CardsRepository из data-слоя, что нарушает последний принцип SOLID. Для решения этой проблемы можно добавить Interface для CardsRepository, который будет находиться в Domain-слое.

Чрезмерное использование синглтонов ухудшает способность кода быть к тестированию. Дружеская рекомендация: прочесть книгу Роберта Мартина Чистая архитектура и изучить проект на github.

Монолитность проектов

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

Отсутствует разделение кода на слои Clean Architecture: data, domain, presentation

В одном из решений CardsInteractor обращается к Storage напрямую и загружает картинки из сети. Хотелось бы видеть тут разделение ответственности. Например, часть логики из CardsInteractor вынести в Repository и DataSource. CardsViewModelImpl отвечает за сортировку списка карт, что, вероятно, не должно выполнятся в презентационном слое.

Использование глобальных функций-расширений, таких как CharSequence?.isNotNullAndEmpty, List<T>.isEmpty

На наш взгляд, использовать подобные функции избыточно. Вместо них можно использовать, к примеру, функции-расширения языка Kotlin CharSequence?.isNullOrEmpty(), isEmpty() и т.д.

Использование неочевидных названий для переменных

Как пример view с названиями info1TitleTextView, info2TitleTextView, info3TitleTextView, info4TitleTextView. На первый взгляд тяжело сказать, чем отличаются данные view. Хочется видеть более говорящие названия.

Использование deprecated методов

Для примера в одном из проектов используется window.decorView.systemUiVisibility, View.SYSTEMUIFLAGLAYOUTFULLSCREEN, SYSTEMUIFLAGLAYOUTHIDE_NAVIGATION. Использование deprecated методов можно смело относить к техническому долгу, с которым рекомендуем бороться как можно быстрее.

Что понравилось с технической стороны

Многомодульность некоторых проектов и следование принципам Clean Architecture

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

Навигация

Во многих решениях сделаны плавные переходы между экранами в виде общих элементов.

Слава богам, что мы не нашли реализаций навигации через неявные интенты :)

Что понравилось с продуктовой стороны

#1 Хороший поиск и дизайн горизонтального скролла

#2 3д карта, интересный подход с быстрым доступом к штрихкоду из списка и общий элемент в навигации

#3 Понравилась группировка карт и удобный скролл к нужной группе

Спасибо за ревью команде жюри: Филиппу Шубину, Константину Степаненко, Константину Малкову, Николаю Ашанину, Андрею Бусику, Богдану Маншилину, Александру Пряничникову, Антону Давыдову, Александру Юдину, Семёну Задорожному, Кириллу Белоглазову.

Спасибо всем участникам! Надеемся в будущем ещё порадовать сообщество разработчиков подобными активностями.

А ещё недавно мы запустили телеграм-канал Cardsmobile | Кошелёк Engineering, в котором делимся опытом разработки, интересными историями и новостями не только команд iOS и Android, но также QA и backend. Рады там всем, нам будет интересно обменяться опытом решения подобных задач и с другими компаниями.

Подробнее..
Категории: Kotlin , Программирование , Разработка мобильных приложений , Разработка под android , Разработка под ios , Android , Swift , Ios , Спортивное программирование , Блог компании cardsmobile , Конкурс разработчиков , Соревнование , Кошелёк , Ищем таланты

Как мы загружали банковскую карту из iPhone в брелок

18.08.2020 14:15:47 | Автор: admin

С каждым годом всё больше компаний проявляют интерес к проектам, связанным с интернетом вещей (Internet of Things, IoT).

В статье я расскажу о созданной нами IoT платформе, о способах загрузки банковских карт в носимые устройства, об исследовании возможностей фреймворка Core NFC iOS и о возможной схеме мошенничества с использованием смартфонов с NFC.

Статья может быть полезна руководителям продуктов, технологам, iOS разработчикам, QA инженерам, которые занимаются мобильными платежами, а также всем, кто интересуется технологиями финтех-отрасли, для расширения кругозора.

Привет, Хабр!


Меня зовут Максим. Промышленной разработкой я занимаюсь с 2005 года. В Кошельке работаю с 2013 года, а с 2015 года помогаю бизнесу компании развивать новые финтех-сервисы в качестве руководителя подразделения.

В Кошельке наша команда запустила немало инновационных продуктов. Это и одна из первых в мире полностью виртуальная банковская карта в смартфоне с возможностью бесконтактной оплаты (за год до запуска Apple Pay в России и задолго до запуска Apple Card), и первая транспортная карта, и первая карта болельщика, и первая кампусная карта в смартфоне.

В прошлом году мы совместно с Mastercard запустили сервис Кошелёк Pay единственный в мире сервис, который, в отличие от аналогов, работает независимо от производителя смартфона или операционной системы. Например, Кошелёк Pay работает на смартфонах Huawei, на которых отсутствуют сервисы Google.

Благодарности


Коле Ашанину, который замотивировал меня на написание статьи и помогал по ходу её подготовки к публикации.

Саше Прыймак, который под моим руководством выполнил описанное в статье исследование.

Также большое спасибо за участие и поддержку:
Кате Туркиной, Антону Давыдову, Лёше Ершову, Даше Алексеенко.

Платформа IoT


На данный момент мы с командой работаем над запуском платформы интернета вещей, которая сможет дополнить и расширить существующий опыт использования сервиса Pay и внедрить оплату (и другие сервисы идентификации) в те вещи, которые мы обычно носим с собой так называемые носимые устройства.

Интернет вещей это концепция привычных физических предметов, оснащенных технологиями для взаимодействия с внешней средой или друг с другом.

В этой концепции привычные сценарии использования вещей перестраиваются благодаря автоматизации.

Пример носимых устройств умные часы, фитнес-браслеты, кольца, брелоки.

Если раньше человек носил кольцо из-за красоты или символизма, то теперь, в концепции интернета вещей, кольцо выполняет функцию платежного инструмента, пропуска СКУД, пульта управления другими умными устройствами и т.д. Таким образом, для привычной вещи появляются новые удобные сценарии использования.

Умные вещи сейчас мировой тренд. Об этом свидетельствуют собранные различными мировыми агентствами статистические данные (см. ссылки в конце статьи).

В этой статье я хочу на примере проведенного нами исследования в рамках разработки IoT-платформы рассказать, с какими задачами работает финтех-направление приложения Кошелёк, с какими проблемами мы сталкиваемся и как используем проверенные технологии карточной индустрии для создания новых продуктов.

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

  1. Элемент безопасности, или Secure Element это полноценный компьютер, выполненный в цельном кристалле кремния размером около 5-20 квадратных миллиметров. Он имеет свою операционную систему, систему ввода-вывода, центральный процессор, несколько крипто-процессоров для реализации криптографических операций, оперативную и постоянную память. Элементы безопасности используют при производстве банковских карт, SIM-карт, а также встраивают в смартфоны и другие устройства. Элемент безопасности практически невозможно взломать и получить оттуда данные (отсюда и название).

    Как и на любой компьютер, в элемент безопасности можно установить приложения так называемые апплеты. Мы в нашей статье будем работать с платежным апплетом, благодаря установке и персонализации которого носимое устройство с элементом безопасности и имеет сервис бесконтактной оплаты.
  2. Стандарт GlobalPlatform Card Specification он описывает работу операционной системы элемента безопасности в целом, а также сценарии и протоколы безопасного управления содержимым элемента безопасности.
  3. TSM (Trusted Service Manager) сервис для управления содержимым в элементе безопасности. Он управляет жизненным циклом апплетов и их персонализацией под конкретного пользователя на конкретном элементе безопасности.
  4. Для превращения носимого устройства в платежный инструмент платежными системами применяется технология токенизации по стандарту EMV это процесс получения от платежной системы токена (суррогатного номера), связанного с номером реальной банковской карты. Для каждой банковской карты, в связке с форм-фактором устройства оплаты, токен всегда уникален, что обеспечивает дополнительную безопасность при оплате токеном.

Вот основные сценарии взаимодействия смартфона с самим устройством, которые мы закладываем в нашу платформу (во всех сценариях пользователь управляет носимым устройством через интерфейс мобильного приложения на смартфоне):

Первый сценарий это взаимодействие с активными носимыми устройствами. Активными называют носимые устройства, в которых есть свой элемент питания (например, аккумулятор). Как правило, внутри вещи работает своя операционная система и имеется модуль BLE для связи со смартфоном. Производитель устройства предоставляет SDK и ключи доступа для взаимодействия с элементом безопасности.

Именно так работают все умные часы и фитнес-браслеты с функцией бесконтактной оплаты.Тут всё просто и понятно берем и делаем.

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

Проблема заключается в том, что нужно загрузить в пассивное носимое устройство свою банковскую карту из приложения на смартфоне.

Этот сценарий мы (условно) разбиваем уже по типу смартфонов:

  1. Любые смартфоны без NFC
  2. Смартфон Android c NFC
  3. iPhone c NFC

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

Реализация терминала персонализации может быть разной: может быть тот же смартфон пользователя, подключенный к внешнему считывателю смарт-карт по BLE или USB, а может быть и автономное внешнее устройство (полноценный компьютер с подключенным к нему считывателем, выходом в интернет и управляющим программным обеспечением).

Для второго типа (Android c NFC) реализация понятна. Смартфон в этом случае можно использовать в качестве терминала, запитать пассивное устройство от NFC-антенны и загрузить в него токен банковской карты.

В нашем исследовании я подробно распишу, как мы прорабатывали третий тип смартфонов (iPhone с NFC). В качестве носимых устройств мы использовали брелки от компании ISBC партнера, с которым мы запускаем пилот.

Цель исследования


Можем ли мы дать возможность пользователю Кошелька на платформе iOS загрузить свою банковскую карту в носимое устройство, приложив его к iPhone?

То есть:

  1. Пользователь в приложении приложении Кошелёк вводит данные своей банковской карты
  2. Пользователь прислоняет к задней стенке iPhone носимое устройство
  3. Банковская карта загружается в носимое устройство

Соответственно, техническая задача определить, можно ли во внешний элемент безопасности (Secure Element) загрузить банковскую карту, используя обычный iPhone и его NFC антенну, через протокол ISO/IEC 7816 (T=CL).

Дополнительные задачи:

  1. Получить ATR (Answer To Reset) чипа, не убирая его от считывателя
  2. Получить UID (Unique Identifier) чипа

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

Что имеем:

  • iPhone 8 c iOS 13.5
  • Тестовое носимое устройство брелок ISBC со встроенным чипом JCOP 3 EMV P60 и загруженными апплетами производства NXP:
    PPSE и апплет, реализующий спецификацию M/Chip Advance Card Specification Payment and Data Storage v1.1;
  • ключи от Issuer Security Domain чипа.

Решение


В начале декомпозируем основную задачу, а именно определим шаги, необходимые для превращения совершенно обыкновенного брелка (ну, почти) в полноценное платежное средство:

  1. Установление соединения чипа с NFC модулем iPhone
  2. Установка на чип апплетов Mastercard M/Chip Advance и PPSE
  3. Персонализация апплетов

Установление соединения


Именно здесь речь пойдет о фичах фреймворка Core NFC, добавленных в iOS 13.
Кстати, в iOS 14 никаких существенных изменений относительно предмета статьи не случилось, поэтому все описанное актуально и для нее.

Итак, в тринадцатой версии яблочной ОС стало возможным не только считывать данные с NFC меток, как это было в iOS 12 (но не раньше iOS 11, до нее взаимодействие по NFC было возможно только в рамках Apple Pay), но и записывать их, а также общаться на языке APDU-команд с любым чипом, который соответствует одному из следующих стандартов:


Для этого в Core NFC были добавлены два новых класса: NFCNDEFReaderSession и NFCTagReaderSession.

Первый используется для взаимодействия с NDEF метками, а второй для всего остального, соответственно.

В нашем случае это чип, поддерживающий спецификацию GlobalPlatform Card Specification 2.2.1 и стандарт ISO/IEC 7816, значит, будем использовать второй класс.

В документации написано, что нужно сделать (помимо написания кода, конечно), чтобы начать общение с чипом по ISO 7816:


Но ниже есть вот такое интересное ограничение:

Important
Core NFC doesn't support payment-related Application IDs.

Как раз его мы и хотим пощупать, узнав, что конкретно оно означает.

Добавляем строку, например Allow NFC connection для ключа NFCReaderUsageDescription в файле info.plist. С любым другим значением этого ключа тоже работает.


[Здесь в колонке слева не сам ключ, а его описание, XCode прячет формальные названия]

Дальше, если мы хотим взаимодействовать с чипом, как с устройством стандарта ISO/IEC 7816, то в значении ключа com.apple.developer.nfc.readersession.iso7816.select-identifiersукажем список ID всех апплетов (Application Identifier или AID), с которым будет взаимодействовать приложение.


Здесь стоит пояснить, что эти идентификаторы не просто случайный набор символов.
Это шестнадцатеричные (hex) строки, содержащие информацию о приложении, которому они присвоены.

AIDы могут быть длиной от 5 до 16 байт (два символа в строке = один байт). Они состоят из двух частей, первая определяет провайдера приложения (для Mastercard это A000000004), вторая говорит, какой именно это продукт данного провайдера (для продукта с именем Mastercard это 1010, а, например, для Maestro это 3060).

Кроме того, иногда в AID требуется поместить дополнительную информацию, например, если на чипе находятся два одинаковых приложения от одного провайдера, но для разных банков. Для этого существует поддержка Long AID (или Extended AID). До тех пор, пока длина AID не превышает 16 байт, в него можно записывать все, что угодно. Например, мы взяли Mastercard AID и в конце дописали к нему TEST, итог: A0000000041010BB5445535401.

Единственный AID, который выбивается из списка 325041592E5359532E444446303101.
На самом деле это обычная (только в hex-формате), что называется, plain-text строка 2PAY.SYS.DDF01. Это AID PPSE, который платежным апплетом, как таковым, не является. Он лишь содержит данные окружения, необходимые платежным приложениям.

Установка апплетов


Для установки апплетов на чип необходимо защищенное соединение (Secure Channel Protocol или SCP); мы сделали это за кадром с помощью обычного PC/SC считывателя и платформы Cardsmobile TSM.

Однако, даже если у вас ничего из этого нет, вы все равно можете попробовать установить свой собственный апплет на чип только на виртуальный.

Понадобится любая IDE с поддержкой JCOP Shell и эмулятором JavaCard, например, вот эта.

Создаем пустой проект, указываем желаемый AID (например 0000000000) и запускаем.

Дальше разбираемся по шагам:

  1. /card
    Получаем ATR, отправляем SELECT без идентификатора, чтобы был выбран Card Manager;

  2. auth
    Создаем защищенное соединение с эмулятором, иначе ничего установить не получится;

  3. ls (опционально)
    С помощью этой команды можно увидеть, какие приложения установлены на вашем девайсе/эмуляторе;

  4. install [packageAID] [appletAID] [instanceAID]
    Устанавливаем апплет:
    packageAID идентификатор пакета (Module), например, 0000000000
    appletAID идентификатор апплета (Load File), например, 000000000000
    instanceAID идентификатор, который будет присвоен вашему апплету после установки, например, A0000000041010;

  5. ls
    Проверяем, появился ли ваш апплет в списке установленных приложений:


Персонализация апплетов


На самом деле, персонализация апплета очень простая штука; всё, что требуется, это загрузить в него необходимые платежные данные. Для этого нужно выбрать апплет командой SELECT по его AID, установить защищенное соединение и отправить выбранному апплету команды STORE DATA с данными внутри.

Теперь вернемся к списку AIDов в файле info.plist зачем он нужен, и как конкретно Core NFC выбирает, с каким апплетом взаимодействовать?

Выглядит это примерно так:

  1. Программа идет по списку сверху вниз;
  2. Для каждого AID она формирует и отправляет команду SELECT;
  3. AID первого апплета, ответившего 9000 (статус успешного ответа, здесь список всех возможных ответов) записывается в поле initialSelectedAID объекта типа NFCISO7816Tag, который кладется в массив обнаруженных чипов

@available(iOS 13.0, *)public protocol NFCISO7816Tag : NFCNDEFTag, __NFCTag {/*** @property initialSelectedAID The Hex string of the application identifier (DF name) selected by the reader when the tag is discovered.*               This will match one of the entries in the com.apple.developer.nfc.readersession.iso7816.select-identifiers*               in the Info.plist.*/@available(iOS 13.0, *)var initialSelectedAID: String { get }


Дальше из массива можно выбрать любой такой объект, и с помощью метода sendCommand отправлять APDU-команды выбранному апплету.

А теперь поговорим об этом ограничении:

Core NFC doesn't support payment-related Application IDs.

То есть Core NFC не поддерживает платежные AIDы, а именно боевые, с которыми работают платежные терминалы.

Конечно, платежный AID в список info.plist добавить можно, вот только Core NFC его проигнорирует и не будет отправлять для него SELECT (кстати, здесь список всех использующихся AID'ов). Apple таким образом защищают свою технологию Apple Pay, закрывая сторонним разработчикам доступ к любым платежным функциям iPhone (и всему, что с этим связано).

Обходные пути


Первое, что приходит в голову а можно ли добавить в info.plist не AID платежного апплета, а AID Card Managerа (Card Manager это группа сервисов внутри операционной системы чипа, управляющих картой, которые отвечают за администрирование и безопасность), чтобы потом вручную послать ему команду SELECT с AID нужного апплета?

Здесь мы споткнулись о первый подводный камень Core NFC не позволяет отправлять команду SELECT, содержащую AID, который не прописан в info.plist.

Хорошо, добавили A0000000041010, но и тут неудача Core NFC не позволяет отправлять команду SELECT, содержащую платежный AID, вне зависимости от того, есть он в info.plist или нет.

Разберемся, как именно работает ограничение по идентификаторам.

В info.plist мы указали следующие AIDы:
1. A000000001510000 - GlobalPlatform Card Manager AID
2. 325041592E5359532E444446303101 - Proximity Payment System Environment (PPSE)
3. A0000000041010 - Mastercard Credit/Debit (Global)
4. A00000000401 - Mastercard PayPass
5. A00000000410101213 - Mastercard Credit
6. A00000000410101215 - Mastercard Credit
7. A00000000410101214 - Придуманный платежный AID
8. A00000000410101216 - Придуманный платежный AID
9. A0000000041010121F - Придуманный платежный AID
10. A0000000041010BB5445535401 - Придуманный платежный Long AID
11. A0000000041010BB5445535405 - Придуманный платежный Long AID
12. A000000004101FBB5445535401 - Придуманный не платежный AID
13. A000000004101F1213 - Придуманный не платежный AID
14. A00000000F1010 - Придуманный не платежный AID
15. A0000000040F - Придуманный не платежный AID

Мы установили 14 платежных апплетов с разными AID (пп. 2-11 платежные AID-ы), и попробовали отправить Card Manager команды SELECT с каждым из этих AID.

Ответили номера 12-15.

Получается, что ограничение накладывается именно на некий префикс AID, наличие которого и определяет, платежный это идентификатор или нет.

Жаль, но этот способ отпадает.

Второй способ персонализации, предусмотренный GlobalPlatform, это команда INSTALL [for personalization].


Она отправляется в Card Manager и содержит AID апплета, который нужно персонализировать.

После этого можно отправлять команды STORE DATA в Card Manager, а он будет пересылать их в целевое приложение.

Но есть одно ограничение. Для того, чтобы апплет поддерживал такой способ персонализации, он должен реализовывать интерфейс org.globalplatform.Application.

Card Manager, на команду INSTALL [for personalization] с Mastercard Credit/Debit (Global) AID, который был присвоен апплету M/Chip Advance от NXP, отвечал ошибкой 6985 (Conditions of use not satisfied),

а значит надо проверить, реализует ли он интерфейс Application.

Для этого мы написали простое приложение-пустышку, реализующее этот интерфейс. Как и ожидалось, на INSTALL [for personalization] оно ответило 9000.

Но когда Application был убран из интерфейсов, реализуемых приложением, оно стало отвечать на эту команду 6985, как и в случае с апплетом M/Chip Advance.

Следовательно, проблема именно в том, что приложение NXP не реализует необходимый для такого способа персонализации интерфейс. Этот способ тоже отпадает.

Дополнительные задачи


  1. Получение UID чипа
    Это сделать можно, очень простым способом.
    При старте сессии NFC модуль ищет чипы, AID'ы апплетов которых прописаны в info.plist, и складывает их в массив.
    После этого любой из них можно оттуда достать, и если его тип NFCISO7816Tag, то у него есть поле identifier, в котором и находится UID чипа.
    /** * @discussion The hardware UID of the tag.*/var identifier: Data { get }

  2. Получение ATR чипа
    А вот ATR, похоже, Core NFC получать не умеет, потому что во фреймворке для этого нет отдельных инструментов, а с помощью APDU-команд ATR получить нельзя.

Выводы


Что же в сухом остатке?

  1. Мы научились работать с чипами стандарта ISO/IEC 7816 (в том числе и получать их UID), используя новые возможности фреймворка Core NFC;
  2. Разобрались с ограничениями, наложенными Apple на свою технологию;
  3. Выяснили, что на данный момент, используя iPhone, персонализировать апплеты с платежными идентификаторами, при этом не реализующие интерфейс Application невозможно;
  4. Взяли на заметку, что с любыми другими AID все работает на ура эти знания пригодятся нам в будущем при работе с нефинансовыми сервисами.

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

В рамках поставленной задачи мы остановились на использовании внешнего BLE считывателя для загрузки токена банковской карты из iPhone в пассивное носимое устройство.

Надеемся, что в будущем Apple расширит возможности NFC Core для выполнения этой и ряда других задач, связанных с токенизацией и оплатой в сторонних приложениях. Впрочем, недавняя новость сигнализирует, что это вряд ли случится в ближайшем будущем.

Побочный результат исследования


В ходе проведения работ родилась схема потенциального мошенничества, которую нельзя воспроизвести посредством смартфонов Apple,

но вполне можно реализовать через Android-смартфон с поддержкой NFC и технологией Host Card Emulation.

Суть вкратце:

  • первый смартфон будет использоваться в качестве терминала, то есть подключаться к банковским картам и взаимодействовать с их платежными апплетами,
  • второй смартфон в качестве платежного средства (на кассе будет выглядеть как обычная оплата смартфоном).

Используя эту схему, можно создать цепочку банковская карта смартфон смартфон платежный терминал, а именно:

  1. Первый смартфон прикладывается к любой банковской карте;
  2. Второй прикладывается к платежному терминалу;
  3. Второй смартфон эмулирует банковскую карту, пересылая APDU-команды, посылаемые терминалом, первому смартфону;
  4. Первый смартфон транслирует эти команды приложенной банковской карте, передавая ее ответы второму смартфону;
  5. Второй смартфон передает полученные ответы терминалу;
  6. Платеж произведен.

То есть потенциально мошенник может приложить смартфон к вашему карману и оплатить покупку. Будьте осторожны!

Чтобы не стать жертвой подобной схемы мошенничества, вы можете, например, перенести банковские карты в смартфон и не носить с собой пластик.

Вместо заключения


Статью я старался писать простым языком, не сильно углубляясь в терминологию предметной области. В ней я описал один из инновационных проектов, над которым мы работаем, предметную область и небольшое исследование новых возможностей iOS фреймворка Core NFC.

Приветствую любую обратную связь:
вопросы, отзывы, комментарии, дополнения, конструктивную критику.

Полезные ссылки


Если вас заинтересовала тема, описанная в статье, то ниже несколько ссылок для более подробного изучения:
  1. Книга И. М. Голдовского Банковские Микропроцессорные Карты
  2. Концепция EMV Payment Tokenisation
  3. Статьи с анализом рынка IoT:

Подробнее..
Категории: Интернет вещей , Разработка под ios , Iot , Исследования и прогнозы в it , Habr , Блог компании cardsmobile , Cardsmobile , Туториал , Кошелёк , Носимые устройства

Кошелёк запускает конкурс мобильных разработчиков с призовым фондом в 1 000 000 рублей

02.11.2020 12:06:03 | Автор: admin
Полчаса назад мы запустили Кошелёк Mobile Challenge конкурс для iOs и Android разработчиков, в котором можно решить реальный кейс приложения и заработать от 100 до 250 тысяч рублей. Лучших участников мы также пригласим в команду, чтобы вместе запустить наш сервис на европейских рынках в 2021 году.




Мы, Cardsmobile, разработчик приложения Кошелёк, запустили конкурс мобильных разработчиков Кошелёк Mobile Challenge, он будет проходить со 2 ноября по 15 декабря. Приём заявок идёт до 4 декабря, оценка работ членами жюри с 5 по 14 декабря, а оглашение победителей случится уже 15 декабря.

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

Ближе к середине конкурса мы сделаем пост с ревью присланных работ, рассказав про самые любопытные варианты решения задачи. Затем у вас будет ещё две недели, чтобы запрыгнуть в последний вагон конкурса, а уже 15 декабря мы объявим имена троих победителей для каждой платформы, которые поделят между собой денежный призовой фонд. И для iOS, и для Android он будет распределяться так:

1 место 250 000 рублей
2 место 150 000 рублей
3 место 100 000 рублей

Лучших мы будем рады пригласить в команду: в следующем году мы запускаем приложение на нескольких европейских рынках, будет здорово делать это вместе. Мы молоды, но уже достаточно известны; умеем делать то, чего не делал никто до нас и не боимся рисковать. Присоединяйтесь! Объединяться в команды для решения задач тоже можно, но помните, что в этом случае приз придётся делить на всех.

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

Критерии оценки заданий просты: это чистота и расширяемость кода, скорость и отзывчивость интерфейса, стабильность работы и процент поддерживаемых версий ОС и устройств. Конечно, и оригинальность идеи сыграет роль. В основной состав жюри вошли: руководитель клиентской разработки Николай Ашанин, руководитель продуктового направления Константин Степаненко, руководитель Android-разработки Андрей Бусик и операционный директор Филипп Шубин. Помогать с разбором заданий будут лиды разработки iOS и Android, продуктовые менеджеры и аналитики, то есть бОльшая часть техкоманды.

Но и это ещё не всё! Конкурс поддерживают наши друзья из образовательного портала GeekBrains. Каждому участнику ребята подарят скидку 45% на курсы по программированию (промокод придёт на вашу почту после отправки задания), а победителям любой курс на выбор. Заманчиво? Пожалуй.

P.S. Ну а чтобы познакомиться получше и делиться новостями, мы запустили ещё и соцсети команды. Будем показывать, что происходит в нашем офисе в сердце Петроградской стороны и кто работает над продуктом. Инстаграм вот здесь, Вконтакте тут, и да, даже Facebook. Классический вид на питерские крыши и обзор офисного кикера прилагаются.

Спишемся!
И удачи!
Подробнее..
Категории: Разработка мобильных приложений , Тестирование мобильных приложений , Мобильные приложения , Дизайн мобильных приложений , Мобильная разработка , Конкурс , Блог компании cardsmobile , Cardsmobile , Geekbrains , Кошелёк

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru