Защита внешних ресурсов, необходимых для платного приложения для iPhone - PullRequest
0 голосов
/ 11 ноября 2009

Я разработал приложение, которое в настоящее время находится в магазине приложений и весит чуть более 400 МБ. Основная причина этого заключается в том, что в приложении много видео, которое в данный момент встроено в двоичный файл.

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

Проблема в том, что люди, у которых нет приложения, смогут загружать наши видео, предназначенные для оплаты клиентов через Интернет, если мы просто используем стандартные URL-адреса для mp4. Есть ли способ защитить эти видео, чтобы их нельзя было легко украсть? (Я говорю «легко», так как я уверен, что после загрузки видео люди всегда могут найти способы вырвать их из приложения и поставить их на небольшой поток, но если они крадут, было бы хорошо, если бы мы этого не сделали ». платить за пропускную способность ...)

Я подумал, что, возможно, мы могли бы как-то сгенерировать одноразовые URL-адреса, которые запрашиваются с использованием какого-то хеш-кода UDID устройства, а затем проверяются на сервере, а затем позволяют пользователю загружать данные через него. Или это просто ерунда?

Какое разумное решение этой проблемы?

Заранее спасибо,

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

Будет ли это работать как решение: (простите за мой язык, обычно на стороне клиента)

1) На стороне сервера каждые 5-10 минут генерируется случайный токен, который может запрашивать приложение.

2) Как только приложение получает этот токен, оно использует его, UDID устройства и секретный ключ, запеченный в приложении, для создания другого токена через md5 или что-то еще

3) Устройство отправляет запрос на сервер с НОВЫМ токеном и UDID устройства

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

Будет ли это работать?

Ответы [ 5 ]

2 голосов
/ 12 ноября 2009

Я думаю, что ваше предложение согласуется с тем, что я бы предложил.

В качестве примера рассмотрим подход Amazon S3 к истечению срока действия ссылки. Я написал следующий помощник на PHP для генерации этих ссылок (работает вместе с Zend____Crypt____Hmac Zend Framework, для получения дополнительной информации см. http://framework.zend.com/wiki/pages/viewpage.action?pageId=35309):

    public function getExpiredQueryString($objectName, $expireTime, $bucketName){
          $stringToSign = "GET\n\n\n$expireTime\n/$bucketName/tracks/$objectName";
          $hashedSignature = Zend_Crypt_Hmac::compute(self::AMAZON_AWS_SECRET_KEY, 'sha1', utf8_encode($stringToSign));
          $signature = urlencode($this->_hex2b64($hashedSignature));

          $url = 'http://' . $bucketName . '.s3.amazonaws.com/tracks/' . $objectName . '?AWSAccessKeyId=' . self::AMAZON_AWS_KEY . '&Expires=' . $expireTime . '&Signature=' . $signature; 
          return $url;
    }

Ниже приводится содержимое _hex2b64 (не оригинальное, но полезное для просмотра):

    private function _hex2b64($str){
          $raw = '';
          for ($i=0; $i < strlen($str); $i += 2)
          {
              $raw .= chr(hexdec(substr($str, $i, 2)));
          }
          return base64_encode($raw);   
     }

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

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

Надеюсь, это поможет!

1 голос
/ 11 ноября 2009

Вы можете предложить приложение бесплатно и предоставить видео в качестве покупки в приложении. Существует API, который ваш сервер может использовать для проверки квитанций IAP, чтобы убедиться, что клиент действительно законно приобрел товар через Apple.

0 голосов
/ 11 ноября 2009

Я считаю, что шифрование данных работает хорошо. Пусть iPhone отправит случайный ключ, зашифрует его на сервере, расшифрует на iPhone. Используйте AES, 128 бит в режиме CBC. Если вам нужна более высокая производительность, вы можете подумать о шифровании только части файла, скажем, 10% с блоками, равномерно распределенными по файлу, это компромисс, что результирующее видео не будет стоить просмотра по сравнению с сохраненным временем шифрования.

0 голосов
/ 11 ноября 2009

Прочтите Модель продукта сервера и Проверка квитанций магазина в Руководстве по программированию в приложении Покупка. Это объясняет, как сделать это довольно безопасным способом.

0 голосов
/ 11 ноября 2009

Приложение iPhone всегда может отправить запрос на сервер, который включает его IP-адрес; затем на вашем сервере верните URL-адрес для загрузки, который разрешает доступ только к этому IP-адресу.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...