今年の飛び石ゴールデンウィークもあっという間に終わってしまいました。

先月はOpenSSLのHeartbleed脆弱性1、Apache Struts2の脆弱性2、Microsoft Internet Explorerの脆弱性3などが公表され、多くのメディアに対応策とともに取り上げられていました。

さて、コーポレートサイトにもある通り、アイリッジはスマートフォン関連サービスを中心に提供しています。 スマートフォンでは多くのプライバシーデータを保持・利用しているため、必然的にアイリッジのサービスはプライバシーを取り扱い、それらを扱うのに必要なセキュリティ要求を満たす必要が出てきます。

今回の記事ではアイリッジが関連するセキュリティの事例についてSSL/TLS界隈の現状に触れようと思います。

SSL/TLSの代表的な利用例がHTTPSプロトコルですが、それ以外にもIMAPやPOP3にIMAPS/POP3S、SSL-VPNなどとしても利用されており、広く普及しています。

HTTPSプロトコルの内部はHTTPプロトコルであるため、普段アプリケーションエンジニアは通信の暗号化について特に意識せず、フィーチャーにフォーカスして開発を行なうことができる状況なので望ましい面もある一方、少人数チームになりがちなスタートアップやベンチャー、大企業の新規事業部ではエンジニア一人あたりの担当範囲が広くなりますので、必要となる背景や知識、経験も求められるように思います。

RSAとその代替

現時点でのSSLで用いる公開鍵暗号方式はRSAです。 強度を決定する要因はキーサイズ(鍵長)ですが、キーサイズ1024ビットは大手SSL認証局の推進もあり、当初の予定から3年遅れたものの、2013年末で廃止され、2014年の現時点では2048ビット公開鍵が利用されるようになったため、一定のセキュリティ強度は保たれているとされています。

RSAのセキュリティ強度をさらに上げていくためには、ビット数を3072, 4096と増やしていくことが必要であり、アメリカのNIST(国立標準技術研究所)は2030年までにRSAキーサイズを3072ビット以上に引き上げるよう勧告しています。 素因数分解を利用したRSA方式では、処理に時間がかかるため、ECC(Elliptic Curve Cryptography)と呼ばれる方式が2013年頃から実際の環境で使われるケースが多くなってきました4。 ECC256ビットがRSA3072ビットと同等のセキュリティ強度を有するため5、セキュリティ強度を維持したまま、SSL通信にかかる計算量を大幅に減らすことができるテクノロジーとして期待されています6

しかし一方で気になるのは、OS/ブラウザの対応状況です。 主要スマートフォンでいうと、Android3.0以降およびiOS 7.0以降で対応していますので、新規でシステムを構築する際は「ECC/RSAハイブリッド構成」を導入していくのがよいかと思われます。 ただし、iOS6.x以前では「ECC/RSAハイブリッド構成」サーバへの接続はできませんので、iOSのサポートバージョンを確認する必要があります。

SHA-2への対応

RSA2048ビット対応だけでは不十分です。 ハッシュアルゴリズムと呼ばれるものも暗号の構成要素の一つです。 広く使われているハッシュアルゴリズムはMD5やSHA-1などがあります。 MD5はビット数が小さく、ハッシュ衝突があることも確認されているため、現在はSSL証明書に、1995年に開発されたSHA-1が用いられています。 NISTはRSAキーサイズ同様に、SHA-1の強度も不十分だとし、2010年末までにSHA-2に移行するように勧告していました。 近年マイクロソフトやシマンテックなどが先導し、2016年末までにSHA-2 (SHA-256)への移行が完了できるのではないかと言われています。 クライアントとしては現時点でのiOS/Androidともに対応しているようですので、スマートフォン向けサービスでは以降が順調に進んでいくと思われます。

Server Name Indication拡張

TLS拡張のうちの一つにServer Name Indication(SNI)いうものがあります。 ただ、Amazon Web Service (AWS)のElastic Load Balancer (ELB)などの普及もあり、SSL terminationする機会も増えてきたため、SNIが使われるケースは以前ほどではなくなっているようにも思います。

SNIはサーバサイド・クライアントサイド同時に対応する必要があるものなので、時に問題となることがあるようです。 デスクトップ環境ではWindows XPのサポートが終了した2014年5月時点では全てのブラウザ(クライアント)が対応していますので、特に問題となることはないようです。 iOSではiOS4.0でSNI対応が導入されていますので、iOSバージョンの状況7を見ると、事実上問題になることはなさそうです。 Androidでは3.0、4.0系では特に問題ありませんが、2.3のブラウザが利用される場合8や、Android 3.0以降でもAndroid SDKに含まれるApache HttpComponentsを利用する際はSNIを使うことはできませんので、注意が必要です。 参考までに2014年1月にリリースされたApache HttpComponents HttpClient 4.3.2においてSNI対応がなされました9ので、今後リリースされるであろうAndroid 4.5またはそれ以降ではこの問題は発生しなくなると思われます。

まとめ

本記事ではSSL/TLSの利用における現状をいくつか紹介してみました。 さらに興味のある方は、ここでは書けなかったブロック暗号モードやメッセージ認証コードなどの種別についても「実システムにおいて、どれを使うべきで、どれを使わないべきか」という観点で調べてみると面白いかもしれません。 情報通信技術は日進月歩ですから、常に最新のセキュリティ技術も追い続けなければいけませんが、サーバーサイドアプリケーション、スマートフォンアプリケーションのみならず、ミドルウェア、クラウド、インフラ、OS、ビッグデータ解析、ストレージ、など幅広い技術とともに複合的なスキルが求められているように思います。

スマートフォン向けサービスを提供しているアイリッジでは、そんなフルスタックエンジニアを募集しています。セキュリティに限らず、関連技術の経験を積んでこられたエンジニアの我こそはという方はご応募ください。


本記事はアイリッジブログで公開していたものをエンジニアリングブログとして再構成したものとなります。記事の内容は、記事執筆当時のものと異なる可能性があります。