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

Пакет приложений «Mobile banking» представляет собой набор, состоящий из двух виджетов, разработанных под мобильную платформу Android версии 4.0 и выше. Техническое задание на разработку виджетов представлено в Приложении А.

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

В связи с этим было решено разработать пакет Android-приложений, а точнее виджетов, «Mobile banking», содержащий:

а) «Currency widget» - виджет обменных курсов валют.

б) «Account widget» - виджет информации по личному счету.

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

«Account widget» отображает баланс конкретного счета клиента, названия и суммы двух последних операций по счету в валюте этих транзакций.

«Currency widget» является виджетом с общедоступной информацией, а «Account widget» отображает информацию и реализует некоторый функционал для конкретного клиента системы «Internet banking», поэтому к нему предъявляются более высокие требования безопасности.

2.1 Разработка требований к обеспечению безопасности

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

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

В нашем случае виджеты выступают в роли клиентского программного обеспечения системы «Internet banking» и следовательно необходимо предусмотреть защиту как самих приложений на локальном устройстве, так и защиту каналов связи с сервером системы.

Для начала рассмотрим общее средство обеспечения безопасности, применяемое для всего пакета приложений. Таким средством является защита канала связи между сервером и Android-приложением посредством протокола SSL (Secure Socket Layer).

Secure Socket Layer

Криптографический протокол SSL (Secure Socket Layer) был разработан в 1996 году компанией Netscape и вскоре стал наиболее популярным методом обеспечения защищенного обмена данными через Интернет. Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений.[17] Протокол SSL обеспечивает целостность и конфиденциальность обмена данными между двумя общающимися приложениями, использующими TCP/IP.

Соединение с использованием протокола SSL позволяет решать следующие задачи:

а) обеспечить сокрытие передаваемой информации, то есть ее защиту от несанкционированного доступа;

б) обеспечить целостность этой информации, то есть ее защиту от случайной или умышленной модификации;

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

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

Цифровые сертификаты в основном служат двум целям: установить личность владельца; сделать доступным первичный ключ владельца.

Цифровой сертификат выпускается и подписывается приватным ключом проверенной полномочной организацией - источником сертификатов (certificate authority - CA) и выдается только на ограниченное время. После истечения срока действия сертификата его необходимо заменить. Так же существуют и самоподписанные сертификаты. [34] Протокол SSL использует цифровые сертификаты для обмена ключами, аутентификации серверов и, при необходимости, аутентификации клиентов. Кроме того сертификаты могут быть самовыпускаемыми.

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

Протокол SSL использует сертификаты для проверки соединения. Эти SSL-сертификаты расположены на безопасном сервере и служат для шифрования данных и идентификации сервера. Сертификат SSL помогает подтвердить, что сервер действительно принадлежит тому, кто это заявляет, и содержит информацию о держателе сертификата, домена, для которого был выдан сертификат, и название источника (CA), выдавшего сертификат.

Есть два способа получить SSL-сертификат:

а) Использовать сертификат от источника сертификатов. Источники сертификатов (CA) - это организации, которым доверяет вся отрасль и которые занимаются выдачей Интернет-сертификатов.[34] Например, такой сертификат можно получить от компании VeriSign. Чтобы получить сертификат, подписанный источником, необходимо предоставить достаточно информации источнику, чтобы он смог проверить вашу личность. Тогда источник создаст новый сертификат, подпишет его и доставит его вам.

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

б) Самоподписанный сертификат - это сертификат, созданный самим пользователем. При использовании такого сертификата издатель совпадает с владельцем сертификата. Удобство такого решения в том, что для создания самоподписанного сертификата нужно меньше времени, чем для получения сертификата, подписанного источником сертификатов. Однако самоподписанный сертификат требует, чтобы любой клиент, подключающийся по SSL к серверу, установившему такой сертификат, был настроен доверять подписавшему сертификат. Так как сертификат был подписан самим пользователем, такая подпись скорее всего не окажется в файле списка доверенных источников клиента и поэтому должна быть туда добавлена. Если получить доступ к такому файлу любого клиента невозможно, то не стоит использовать такую конфигурацию, лучше получить сертификат от проверенного источника. Самоподписанные сертификаты полезны только тогда, когда каждый клиент, взаимодействующий с сервером, можно настроить так, чтобы он доверял данному сертификату.[34]

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

Аутентификация в протоколе SSL осуществляется путем проверки электронно-цифровой подписи. ЭЦП проверяемого субъекта может быть проверена на корректность с помощью его открытого ключа, но при этом создать корректную подпись можно только обладая закрытым ключом субъекта, известным только владельцу (т.е. субъекту). Таким образом, зная открытый ключ клиента и предложив ему подписать случайный блок данных, можно определить его соответствие проверкой подписи.[25]

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

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

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

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

Протокол SSL позволяет серверу и клиенту перед началом информационного взаимодействия аутентифицировать друг друга (clientserver authentification), согласовать алгоритм шифрования и сформировать общие криптографические ключи. С этой целью в протоколе используются двухключевые (ассиметричные) криптосистемы, в частности, RSA. Т. е. один ключ используется для шифрования сообщения, а для его расшифровки необходимо использовать другой. Это позволяет получать защищенные сообщения, просто публикуя один (открытый) ключ и храня другой (секретный) ключ в тайне.

Пара таких ключей обладает следующими свойствами:

а) Зашифрованное с помощью открытого ключа сообщение может быть расшифровано только с помощью соответствующего закрытого ключа.

б) ЭЦП, созданная с помощью закрытого ключа может быть проверена на соответствие с помощью открытого ключа.

Т.к. ассиметричное шифрование довольно медленное, то конфиденциальность информации, передаваемой по установленному защищенному соединению, обеспечивается путем шифрования потока данных на сформированном общем секретном ключе с использованием симметричных криптографических алгоритмов (например, RC4, RC2, DES и др.). Контроль целостности передаваемых блоков данных производится за счет использования кодов аутентификации сообщений (Message Autentification Code, MAC), вычисляемых с помощью хэш-функций (например MD5).[34]

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

Протокол SSL включает три этапа взаимодействия сторон защищаемого соединения: переговоры о типе SSL-сессии; обмен ключами и аутентификация посредством сертификатов, защита потока данных.[25]

На первом этапе стороны договариваются об используемых криптографических алгоритмах.

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

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

Рассмотрим процесс установки безопасного соединения между клиентом и сервером:

В процесс SSL «рукопожатия» входят следующие этапы:

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

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

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

4. Используя все сгенерированные до этого этапа данные, клиент(в зависимости от выбраного метода шифрования) создает предварительный секретный ключ сеанса(premaster secret), шифрует его открытым ключом сервера(полученным из сертификата сервера, который был послан на этапе 2) и посылает его серверу.

5. Клиент подписывает следующую порцию данных, которая уникальная для текущего «рукопожатия» и известна и клиенту и серверу. Если сервер запросил аутентификацию клиента, то клиент посылает серверу кроме подписанных данных и зашифрованного предварительного секретного ключа(pre-master secret) еще и свой сертификат.

6. Если сервер запросил аутентификацию клиента, то сервер пытается аутенфицировать клиента. Если клиент не может быть аутентифицирован, сеанс заканчивается. Если клиент может быть аутентифицирован, сервер использует свой секретный ключ(private key) для расшифрования предварительного секретного ключа(pre-master secret), производит некоторые действия(которые клиент также производил) для того, чтобы сгенерировать секретный ключ(master secret).

7. И клиент и сервер используют секретный ключ (master secret), чтобы создать сеансовые ключи, которые являются симметричными ключами, необходимые для шифрования и расшифрования информации, которой обмениваются во время SSL сеанса и для проверки целостности данных(то есть определения любых изменений данных в моменты времени, когда они посылаются и когда они принимаются).

8. Клиент посылает сообщение серверу, информирующее о том, что будущие сообщения от клиента будут шифроваться сеансовыми ключами. Затем клиент посылает отдельное зашифрованное сообщение, обозначающее, что клиент закончил свою часть «рукопожатия».

9. Сервер посылает сообщение клиенту, информирующее о том, что будущие сообщения от сервера будут шифроваться сеансовыми ключами.

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

10. SSL «рукопожатие» завершено и сеанс начинается. Клиент и сервер используют сеансовые ключи для шифрования и расшифрования данных, которых они посылают друг другу, и для проверки их целостности.

11. Нормальное условие защищенного канала. В любое время, вследствие внутренней или внешней причины, любая сторона провести повторное «рукопожатие», вследствие чего, процесс «рукопожатия» повторится.

Во время «рукопожатия» сервер посылают клиенту сертификат, чтобы стать аутентифицированным. В процесс аутентификации сервера входят следующие этапы:

1. Текущая дата лежит в пределах периода действия сертификата? Клиент проверяет период действия сертификата сервера. Если текущяя дата лежит за пределами периода действия, то процесс аутентификации заканчивается неудачей. Если текущая дата и время лежит в этом пределе, клиент переходит к этапу 2).

2. Проверяемый Certificate Authority (CA) является доверяемым CA? Каждый клиент имеет список доверенных СА сертификатов. Если проверяемый сертификат найден в этом списке, то клиент переходит к этапу 3). Если не найден, то процесс аутентификации заканчивается неудачей.

3. Проверяемый СА открытый ключ удовлетворяет цифровой подписи? Клиент использует открытый ключ СА сертификата чтобы установить достоверность цифровой подписи сертификата. Если информация в сертификате сервера изменилась с момента, когда он был подписан СА, или открытый ключ СА сертификата не соответствует секретному ключу, который был использован СА чтобы подписать СА сертификат, то клиент не аутентифицирует сервер. Если цифровая подпись достоверна, клиент рассматривает сертификат сервера как валидный и переходит к шагу 4).

4. Доменное имя в сертификате сервера совпадает с доменным именем сервера? Этот этап подтверждает, что сервер действительно находится по тому сетевому адресу, заявленному в сертификате. Хотя этап г) не является технической частью протокола SSL, он предоставляет защиту от формы атаки, называемой «человек посередине». Клиент должен выполнять этот этап и должен завершать аутентификацию сервера или установку соединения, если доменные имена не совпадают. Если доменные имена совпадают, то переход на этап 5).

5. Сервер аутентифицирован. Клиент продолжает SSL «рукопожатие».

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

Для передачи общедоступной информации системы «Internet banking» протокол SSL является достаточным средством обеспечения защиты информации, однако, как было сказано ранее, в «Account widget» содержится личная информация клиента, в том числе о его денежных средствах, следовательно, она требует более серьезного уровня защиты. Для этих целей применяется многоступенчатая аутентификация пользователя.

Аутентификация

Основой любых систем защиты информационных систем являются идентификация и аутентификация, так как все механизмы защиты информации рассчитаны на работу с поименованными субъектами и объектами автоматизированной информационной системы.[36] В качестве субъектов автоматизированной информационной системы чаще всего выступают пользователи и процессы, а в качестве объектов - информация и другие информационные ресурсы системы.

Присвоение субъектам и объектам доступа личного идентификатора и сравнение его с заданным перечнем называется идентификацией. Идентификация обеспечивает выполнение следующих функций:

? установление подлинности и определение полномочий субъекта при его допуске в систему;

? контролирование установленных полномочий в процессе сеанса работы;

? регистрация действий и др.

Аутентификацией (установлением подлинности) называется проверка принадлежности субъекту доступа предъявленного им идентификатора и подтверждение его подлинности. Другими словами, аутентификация заключается в проверке: является ли подключающийся субъект тем, за кого он себя выдает.

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

В нашем случае на каждом этапе используется так называемая аутентификация «по факту знания» или «то, что мы знаем». Это тайные сведения, которыми должен обладать только авторизованный субъект. Паролем может быть речевое слово, текстовое слово, комбинация для замка или личный идентификационный номер (PIN). Парольный механизм может быть довольно легко воплощён и имеет низкую стоимость. Но имеет существенные недостатки: сохранить пароль в тайне зачастую бывает сложно, злоумышленники постоянно придумывают новые способы кражи, взлома и подбора пароля. Это делает парольный механизм слабо защищённым.

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

Рассмотрим этапы аутентификации:

Этап 1 - Аутентификация по многоразовому паролю

Один из способов аутентификации в компьютерной системе состоит во вводе вашего пользовательского идентификатора, называемого «логином» (англ. login - регистрационное имя пользователя) и пароля - неких конфиденциальных сведений. Достоверная (эталонная) пара логин-пароль хранится в специальной базе данных.

Простая аутентификация имеет следующий алгоритм:

1. Субъект вводит личный идентификатор и пароль и запрашивает доступ в систему.

2. Введённые неповторимые данные поступают на сервер, где сравниваются с эталонными.

3. При совпадении данных с эталонными аутентификация признаётся успешной, при различии - субъект перемещается к 1-му шагу.

Введенные логин пароль передаются в сети с использованием шифрования протокола SSL. Кроме того пароль шифруется специальной криптофункцией с использованием ключа сессии и расшифровывается другой криптофункцией на сервере. Поскольку данные функции не являются частью протокола SSL, а принадлежат клиентской и серверной части системы «Internet banking», это обеспечивает более высокий уровень защиты передаваемого пароля.

Этап 2 - Аутентификация по символам с изображения (капча)

Капча - это компьютерный тест, используемый для того, чтобы определить, кем является пользователь системы: человеком или компьютером.[25] Пользователь вводит символы, изображённые на рисунке. Обычно на изображение добавляют различного рода помехи, прозрачность, частичное наложение символов и т.д. У пользователя обычно есть возможность запросить другое изображение, если он не может прочитать символы с текущего.

Аутентификация по символам с изображения имеет следующий алгоритм:

1. Сервер подтверждает успешное завершение этапа 1.

2. Субъект получает с сервера изображение.

3. Субъект вводит символы, с полученного изображения.

4. Введённые данные поступают на сервер, где сравниваются с реальными символами, соответствующими данному изображению.

5. При совпадении введенных данных с реальными, аутентификация признаётся успешной, при различии - субъект перемещается ко 2-му шагу.

Этап 3 - Аутентификация по символам секретного слова

Каждый клиент при создании учетной записи в системе «Internet banking» получает некоторое секретное слово, которое он так же может по запросу изменить.

Аутентификация по символам секретного слова имеет следующий алгоритм:

1. Сервер подтверждает успешное завершение этапа 2.

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

3. Субъект вводит символы секретного слова, стоящие на соответствующих позициях и подтверждает ввод.

4. Введённые данные поступают на сервер, где сравниваются с реальными символами, стоящими на позициях с номерами, полученными пользователем на шаге 2).

5. При совпадении введенных данных с реальными, аутентификация признаётся успешной, при различии - субъект перемещается к этапу 2.

Введенные символы секретного слова передаются в сети с использованием шифрования протокола SSL.

Этап 4 - Аутентификация с помощью динамического (одноразового) пароля

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

Отправка таких паролей осуществляется в место назначения, которое напрямую не связано с клиентским приложением. Чаще всего для отправки таких паролей используют электронную почту и SMS-сообщения.

1. Сервер подтверждает успешное завершение этапа 3.

2. Субъект из списка возможных мест назначений выбирает то, куда он хотел бы получить пароль и подтверждает свой выбор.

3. Сервер генерирует одноразовый пароль и отправляет его в соответствующее место назначения.

4. Субъект вводит полученный пароль и подтверждает ввод.

5. Введённые данные поступают на сервер, где сравниваются с ранее сгенерированными эталонными.

6. При совпадении данных с эталонными аутентификация признаётся успешной и пользователь получает доступ к своим личным данным, при различии - субъект перемещается к этапу 2.

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

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

2.2 Разработка требований к графическому интерфейсу

Каждое приложение из пакета «Mobile banking» состоит из двух частей - конфигурационный экран(Configuration activity) и сам отображаемый виджет. После того, как пользователь добавляет один из виджетов на рабочий стол своего устройства, автоматически открывается конфигурационный экран. После того, как пользователь выбрал все необходимые настройки и подтвердил свой выбор, конфигурационный экран закрывается и на виджете отображается вся предусмотренная настройкой информация.

Конфигурационный экран необходим для того, чтобы пользователь мог настроить свой виджет индивидуально, то есть выбрать некоторые параметры отображаемой на виджете информации. Кроме того в случае «Account widget» информацию для аутентификации пользователь будет вводить именно при отображении конфигурационного экрана.

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

Разработка требований к графическому интерфейсу приложения «Currency widget»

Рассмотрим виджет обменных курсов валют - «Currency widget». После добавления виджета на рабочий стол, должен отобразиться конфигурационный экран.

На «рисунке 1» представлено визуальное отображение конфигурационного экрана «Currency widget».

Рисунок 1 - Конфигурационный экран «Currency widget»

После нажатия кнопки подтверждения на рабочем столе должен появиться виджет размером 4x2.

На «рисунке 2» представлено визуальное отображение «Currency widget».



Рисунок 2 - «Currency widget»

Разработка требований к графическому интерфейсу приложения

«Account widget»

Рассмотрим виджет информации по личному счету - «Account widget». После добавления виджета на рабочий стол, должен отобразиться конфигурационный экран. На «рисунке 3» представлено визуальное отображение конфигурационного экрана «Account widget».

Рисунок 3 - Конфигурационный экран «Account widget»

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

На «рисунке 4» представлено визуальное отображение диалога ввода символов с изображения.



Рисунок 4 - Диалог ввода символов с изображения

После нажатия кнопки ввода, при условии верно введенных данных, появляется диалог для ввода символов секретного слова (если этот вид аутентификации настроен для данного пользователя).

На «рисунке 5» представлено визуальное отображение диалога ввода символов секретного слова.

Рисунок 5 - Диалог ввода символов секретного слова

После нажатия кнопки подтверждения, при условии верно введенных данных, появляется диалог для выбора адреса доставки одноразового пароля (если этот вид аутентификации настроен для данного пользователя).

На «рисунках 6 и 7» представлено визуальное отображение диалога выбора адреса доставки одноразового пароля.

Рисунок 6 - Диалог выбора адреса доставки одноразового пароля

Рисунок 7 - Диалог выбора адреса доставки одноразового пароля

После нажатия кнопки подтверждения появляется диалог для ввода полученного одноразового пароля.

На «рисунке 8» представлено визуальное отображение диалога ввода одноразового пароля.



Рисунок 8 - Диалог ввода одноразового пароля

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

На «рисунках 9 и 10» представлено визуальное отображение конфигурационного экрана после аутентификации.

Рисунок 9 - Конфигурационный экран после аутентификации



Рисунок 10 - Конфигурационный экран после аутентификации

После нажатия кнопки подтверждения на рабочем столе должен появиться виджет размером 4x1.

На «рисунке 11» представлено визуальное отображение «Account widget».

Рисунок 11 - «Account widget»

Язык надписей приложений зависит от языка устройства. Виджеты должны поддерживать 2 языка - английский и русский. В случае если язык устройства не русский, компоненты виджетов отображаются на английском.

2.3 Выбор средств разработки

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

Eclipse IDE

Для разработки Android-приложений «Mobile banking» использовалась среда разработки (IDE) eclipse 4.3.2.

Eclipse - это программная платформа с открытым исходным кодом, написанная на языке Java. Основная цель ее создания - повышение производительности процесса разработки ПО.

Большинство пользователей Eclipse используют данную платформу как интегрированную среду разработки Java IDE (Integrated Development Environment). Но ее возможности обширнее. Eclipse также располагает средой разработки плагинов PDE (Plugin Development Environment), которой заинтересуются в первую очередь желающие расширить сам Eclipse.

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

К основным особенностям Eclipse относится:

? кроссплатформенность - стабильная работа под различными операционными системами (Mac OS X, Solaris, Windows, Linux);

? платформа позволяет программировать на множестве языков, среди которых Python, Java, PHP, Cobol, C и C++, Perl;

? для разработки иных инструментов среда является фреймворком и предлагает широкую подборку интерфейсов прикладного программирования для создания модулей;

? использование подхода Rich Client Platform делает Eclipse инструментом, с помощью которого можно создать практически любое клиентское программное обеспечение.

Разработка проекта в Eclipse выполняется в нескольких направлениях, три основные - работа над платформой, разработка Java IDE и создание плагинов с целью расширения функциональности.

Главный элемент архитектуры платформы - исполняющая среда Runtime, в ней выполняются коды модулей и расширений. Она обеспечивает базовую функциональность Eclipse - управление обновлениями и расширениями, взаимодействие с ОС, обеспечение работоспособности системы помощи.

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

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

Android Developer Tools

Для разработки под мобильную операционную систему Android используется один из плагинов, расширяющих возможности eclipse, Android Developer Tools (ADT).

Android Developer Tools представляет собой среду разработки профессионального уровня для создания приложений для Android.[22] Это полный Java IDE с расширенными возможностями, которые помогают создавать, тестировать, отлаживать и упаковывать программы, учитывая все специфические особенности операционной системы Android. ADT обеспечивает разработчика следующими инструментами:

Полная Java IDE

1. Android-специфичный рефакторинг, быстрые исправления, интегрированная навигация между Java и XML ресурсами.

2. Расширенные редакторы XML для Android XML ресурсов.

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

4. Поддержку сложных проектов, поддержка командной работы для непрерывной интеграции через Ant. Включает обфускатор ProGuard и систему подписи приложений.

Обфускация - это процесс, в результате которого код программы приобретает вид, трудный для анализа. Обфускация, как нетрудно догадаться, осуществляется с целью защиты программного кода и алгоритмов, которые он реализует, от чужих глаз, которые, несмотря на строжайшие запреты разработчиков, любят подсматривать за тем, что и каким именно образом написано.[31]

Существует несколько разных видов обфускации в зависимости от того, какой именно код запутывается при ней. Для тех языков программирования, для которых программа представляется прямо в виде исходных текстов, используются специальные методы, делающие код нечитабельным для человека, но приемлемым для интерпретатора. Среди них - запись программы в одну строку, замена имён переменных и функций, вставка ничего не значащих комментариев. Для обфускации двоичного кода (как для исполняемых файлов, так и двоичного кода виртуальных машин .NET и Java) используются уже более серьёзные методы, в том числе и шифрование.

Инструмент ProGuard сжимает, оптимизирует и запутывает код путем удаления неиспользуемого кода и переименования классов, полей и методов в семантически непонятные названия. Результатом является АПК файл меньшего размера, что затрудняет обратное проектирование.[22] Поскольку ProGuard делает ваше приложение сложнее для обратного проектирования, его использование очень важно, когда приложение использует возможности, которые чувствительны к безопасности, например лицензирование.

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

5. Мастер шаблонного создания стандартных Android проектов и компонентов.

Редакторы графического интерфейса

1. Построение любого Android пользовательского интерфейса с помощью перетаскивания визуальных компонентов.

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

3. Редактор поддерживает работу с компонентами пользовательского (custom) интерфейса.

Настройки параметров разработки на устройстве

1. Включение отладки по USB.

2. Получение отчета об ошибках с устройства.

3. Отображение на экране загрузки центрального процессора

устройства.

Разработка на реальных устройствах

1. Использование любого коммерческого Android устройства или нескольких устройств.

2. Развертывание приложения для подключенных устройств прямо из IDE eclipse.

3. Запуск на устройстве отладки, тестирования и профилирования.

Разработка на виртуальных устройствах

1. Эмуляция любого устройства. Используйте нестандартные размеры экрана, клавиатуры и другие аппаратные компоненты.

2. Расширенная аппаратная эмуляция, в том числе камера, датчики, мультитач, телефония.

3. Разработка и тестирование приложения на совместимость с большим количеством устройств.

Мощные инструменты отладки

1. Полный Java отладчик с возможностью отладки на устройствах и Android-специфические инструменты.

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

Тестирование

1. Инструменты тестирования на основе скриптов.

2. Интегрированные отчеты, использующие стандартный пользовательский интерфейс.

3. Создание и запуск тестов модулей на устройстве или эмуляторе.

Native разработка

Поддержка компиляции и упаковки пакетов существующего кода, написанного на C или C + +.

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

Приложения «Mobile banking» разрабатываются с использованием компонентов, добавленных в Android API 14 (Application programming interface), поэтому данные приложения поддерживают Android версии 4.0 и выше.

В данной главе была разработана концепция Android-приложений «Mobile banking». Так же были разработаны требования, предъявляемые к графическому интерфейсу виджетов «Mobile banking» и их конфигурационных экранов, а так же к отображаемой на них информации. Вместе с тем были разработаны требования к функциональности «Currency widget» и «Account widget».

В процессе разработки требований к безопасности работы приложений была детально рассмотрена последовательность установления соединения по протоколу Secure Socket Layer, проанализированы его возможности и принципы работы. Кроме того были разработаны требования к возможным типам аутентификации в приложении «Account widget», рассмотрен порядок взаимодействия пользователя с приложением на каждом этапе аутентификации.

Помимо этого были проанализированы характеристики, функциональность и преимущества выбранных средств разработки, а именно интегрированной среды разработки Eclipse, и плагина Android Developer Tools для разработки под мобильную платформу Android.

На основе предъявляемых требований в качестве основания для реализации виджетов, было разработано техническое задание на разработку Android-приложений «Mobile banking» для системы «Internet banking».



Глава 3. Реализация Android-приложений «Mobile banking»

3.1 Реализация модуля связи с серверной частью системы «Internet banking»

Модуль связи с серверной частью системы «Internet banking» - платформонезависимый модуль, написанный на языке программирования Java с использованием стандартных свободно распространяемых библиотек Java Development Kit (JDK). Это позволяет использовать данный модуль как инструментарий для создания других клиентских приложений системы «Internet banking», в независимости от платформы конечного программного обеспечения.

Модуль связи с серверной частью состоит из следующих классов:

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

«Internet banking».

ConnectionChannel - класс, отвечающий за сетевое взаимодействие сервера и класса ServerConnection.

SimpleXML - класс, предоставленный компанией Compass Plus для упрощения разбора информации, полученной с сервера, а так же для удобной работы со справочниками компании.

Реализация методов данных классов содержит коммерческую тайну, в связи с чем для каждого метода будут рассмотрены только его имя, тип возвращаемого значения, параметры, а так же общее назначение. Реализация класса ServerConnection Поля класса: private String RuResponse - приватная строка формата XML с данными об ответах, возвращаемых сервером, на русском языке.

private String EnResponse - приватная строка формата XML с данными об ответах, возвращаемых сервером, на английском языке.

private String CurrencyIsoXML - приватная строка формата XML содержащая справочник по валютам.

private HashMap<String, String> EnResponseMap - приватная коллекция с элементами ключ-значение. Ключ - код ответа, значение - расшифровка ответа на английском языке.

private HashMap<String, String> RuResponseMap - приватная коллекция с элементами ключ-значение. Ключ - код ответа, значение - расшифровка ответа на русском языке.

private HashMap<String, String> CodeIsoMap - приватная коллекция с элементами ключ-значение. Ключ - код валюты, значение - сокращенное название валюты.

private HashMap<String, String> IsoCodeMap - приватная коллекция с элементами ключ-значение. Ключ - сокращенное название валюты, значение - код валюты. private LanguageSettings Language - приватный объект, хранящий язык инстанции класса.

private String SessionID - приватная строка, содержащая идентификатор сессии.

private String SessionKey - приватная строка, содержащая ключ сессии.

private String AuthKey - приватная строка, содержащая ключ аутентификации.

private String PAN - приватная строка, содержащая идентификатор клиента системы «Internet banking».

private ArrayList<Integer> SecretLettersPos - приватный объект,

хранящий массив номеров позиций символов секретного слова.

private URL DataUrl - приватный объект, хранящий адрес для отправки запросов серверу.

private URL IndexUrl - приватный объект, хранящий адрес для получения идентификатора сессии.

private static Logger logger - приватный объект, предназначенный для вывода логов.

private ConnectionChannel Channel - приватный объект, предназначенный для сетевого взаимодействия сервера и класса

ServerConnection.

Перечисляемые типы класса:

enum LanguageSettings {RUSSIAN, ENGLISH} - перечисляемый тип языковых настроек.

enum RateMode {VALUE, ATTITUDE} - перечисляемый тип формата вывода обменного курса валют. VALUE - число с плавающей точкой, ATITUDE - отношение.

enum RateDirection {BUY, SELL} - перечисляемый тип направления конвертации валюты. BUY - покупка, SELL - продажа.

enum ProtocolSettings {http, https} - перечисляемый тип доступных сетевых протоколов соединения.

Методы класса:

public ServerConnection(ProtocolSettings protocol, String host, int port, String dataFile, String indexFile, LanguageSettings language) throws MalformedURLException Конструктор класса.

Параметры: protocol - протокол сетевого соединения; host - адрес сервера; port - порт сервера; dataFile - путь файла, к которому нужно обращаться, чтобы отправлять запросы на сервер; indexFile - путь файла для получения идентификатора сессии; language - язык инстанции класса.

Возможно возникновение MalformedURLException - исключение, возникающее при неправильном формате формируемых URL.

public static void trustAll();

Приватный метод, предназначенный для установления доверия серверам с самоподписанным сертификатом SSL.

public ConnectionChannel getChannel();

Публичный метод, предназначенный для получения объекта типа ConnectionChannel из поля класса channel.

public ArrayList<Integer> getSecretLettersPos();

Публичный метод, предназначенный для получения объекта типа ArrayList<Integer> из поля класса secretLettersPos.

public String getSessionId();

Публичный метод, предназначенный для получения идентификатора текущей сессии инстанции класса.

private static String getStrFromXmlByPath(String xmlFilePath);

Статический приватный метод, предназначенный для получения содержимого XML файла, находящегося по адресу XmlFilePath, в виде объекта-строки типа String.

public int setRuResponseByPath(String ruResponsePath);

Публичный метод, предназначенный для установления справочника ответов сервера на русском языке, находящегося по адресу ruResponsePath, для инстанции класса. Возвращает 1 при успешном выполнении и 0 при ошибке. Комментарии по ошибке выводятся в лог.

public int setEnResponseByPath(String enResponsePath);

Публичный метод, предназначенный для установления справочника ответов сервера на английском языке, находящегося по адресу enResponsePath, для инстанции класса. Возвращает 1 при успешном выполнении и 0 при ошибке. Комментарии по ошибке выводятся в лог.

public int setCurrencyIsoListByPath(String currencyListPath)

Публичный метод, предназначенный для установления справочника валют, находящегося по адресу currencyIsoXMLPath, для инстанции класса. Возвращает 1 при успешном выполнении и 0 при ошибке. Комментарии по ошибке выводятся в лог.

public int setRuResponse(String newRuResponse);

Публичный метод, предназначенный для установления справочника ответов сервера на русском языке newRuResponse для инстанции класса. Возвращает 1 при успешном выполнении и 0 при ошибке. Комментарии по ошибке выводятся в лог.

public int setEnResponse(String newEnResponse);

Публичный метод, предназначенный для установления справочника ответов сервера на английском языке языке newEnResponse для инстанции класса. Возвращает 1 при успешном выполнении и 0 при ошибке.

Комментарии по ошибке выводятся в лог.

public int setCurrencyIsoList(String newCurrencyIsoXML);

Публичный метод, предназначенный для установления справочника валют newCurrencyIsoXML для инстанции класса. Возвращает 1 при успешном выполнении и 0 при ошибке. Комментарии по ошибке выводятся в лог.

public void setLanguage(LanguageSettings newLanguage);

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

public boolean existSecretWord();

Публичный метод предназначенный для определения, заполнялся ли массив secretLettersPos для данной инстанции. Если да, то возвращает true, если нет - false.

private String getSessionID(URL url);

Приватный метод, предназначенный для получения идентификатора сессии по url. Возвращает null при ошибке. Комментарии по ошибке выводятся в лог.

private String getSessionKey(URL url, String sessionID);

Приватный метод, предназначенный для получения ключа сессии по url и идентификатору сессии sessionID. Возвращает null при ошибке.

Комментарии по ошибке выводятся в лог.

private String getAuthKey(URL url, String sessionID, String sessionKey); Приватный метод, предназначенный для получения ключа аутентификации по url, идентификатору сессии sessionID и ключу сессии sessionKey. Возвращает null при ошибке. Комментарии по ошибке выводятся в лог.

private String getPAN(URL url, String sessionID, String sessionKey,

String authKey, String login, String PIN

String captcha)

Приватный метод, предназначенный для получения идентификатора клиента системы по url, идентификатору сессии sessionID, ключу сессии sessionKey, ключу аутентификации authKey и символов captcha с изображения. Возвращает null при ошибке. Комментарии по ошибке

выводятся в лог.

private static String xorString(String pin, int key);

Приватный криптографический метод, используемый для шифрования пароля pin ключом key.

private ArrayList<Integer> getSecret LettersPosFromGetPANResponse (String getPANResponse);

Приватный метод, предназначенный для получения массива, содержащего номера позиций символов секретного слова из ответа getPANResponse, пришедшего с сервера. Возвращает null при ошибке.

Комментарии по ошибке выводятся в лог.

public int createSession(String login, String PIN, String captcha);

Публичный метод, предназначенный для создания сессии с аутентификацией. Возвращает 1 при успешном выполнении и 0 при ошибке.

Комментарии по ошибке выводятся в лог.

public int fillSecretLettersPos(String login, String PIN, String captcha);

Метод, предназначенный для заполнения массива secretLettersPos, при ошибочно введенных символах секретного слова или элементов другой динамической аутентификации. Возвращает 1 при успешном выполнении и 0 при ошибке. Комментарии по ошибке выводятся в лог.

public int createPublicSession();

Публичный метод, предназначенный для создания публичной сессии, то есть с возможностью получения только общей информации системы «Internet banking», а не по конкретному пользователю. Возвращает 1 при успешном выполнении и 0 при ошибке. Комментарии по ошибке выводятся в лог.

public int login(String secretLetters, String dynamicPassword);

Публичный метод, предназначенный для входа в систему с параметрами: символы секретного слова - secretLetters, динамический одноразовый пароль - dynamicPassword. Возвращает 1 при успешном выполнении и 0 при ошибке. Комментарии по ошибке выводятся в лог.

private String getCards();

Приватный метод, предназначенный для получения с сервера информации о картах клиента в виде строки формата XML. Возвращает null при ошибке. Комментарии по ошибке выводятся в лог.

private String getAcctsRp();

Приватный метод, предназначенный для получения с сервера информации о счетах клиента в виде строки формата XML. Возвращает null при ошибке. Комментарии по ошибке выводятся в лог.

public ArrayList<String[]> getAcctsList();

Публичный метод, предназначенный для получения с сервера информации о счетах клиента в виде объекта ArrayList<String[]>. Каждый элемент коллекции ArrayList содержит номер, валюту, доступный баланс и название счета. Возвращает null при ошибке. Комментарии по ошибке выводятся в лог.

private String getAllVendors();

Приватный метод, предназначенный для получения с сервера информации о всех вендорах (поставщиках услуг) в системе «Internet banking» в виде строки формата XML. Возвращает null при ошибке.

Комментарии по ошибке выводятся в лог.

private String getVendors();

Приватный метод, предназначенный для получения с сервера информации о вендорах (поставщиках услуг) конкретного клиента в виде строки формата XML. Возвращает null при ошибке. Комментарии по ошибке выводятся в лог.

public static String getResponseCode(String xmlTWIBResponse)

Публичный метод, предназначенный для получения кода по ответу, полученному с сервера в виде строки формата XML. Возвращает null при ошибке. Комментарии по ошибке выводятся в лог.

public String getResponseMessageByCode(String responseCode);

Публичный метод, предназначенный для получения расшифровки ответа с сервера по коду. Возвращает null при ошибке. Комментарии по ошибке выводятся в лог.

public String payByTemplate(String fromAcct, String templateNo,

double amount, String period);

Публичный метод, предназначенный для осуществления платежа по шаблону с номером templateNo со счета fromAcct, на сумму amount, с кодом периодичности period. Возвращает null при ошибке. Комментарии по ошибке выводятся в лог.

Значения period:

0 - однократно (немедленно), 1 - ежедневно, 2 - еженедельно, 3 - раз в 2 недели, 4 - ежемесячно, 5 - раз в 2 месяца, 6 - раз в квартал, 7 - раз в год.

public HashMap<String, String> getFormWithValues(String seqNo);

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

public String schedule(HashMap<String, String templateHM, String period);

...