DigiTallyについて調べてみた/overlay SIMが重要なのではなくSMAPsが重要っぽい

2020/09/28 追記

DigiTallyについて述べていた公式サイトが移動していた。もとはKhaled Baqerさんのディレクトリにあったものが、Ross Andersonさんのディレクトリに移動していた。
新しい Computer Laboratoryの DigiTally ページ

いろいろ調べたらKhaled Baqerさんは学生で、Ross Andersonさんが教授だったようだ。Khaled Baqerさん個人ページができていた。

2017年に出た論文「DigiTally: Piloting Offline Payments for Phones

また、日本銀行から「中銀デジタル通貨が現金同等の機能を持つための技術的課題」(2020/07)というレポートの8ページからDigiTallyについて解説されている。

中銀デジタル通貨が現金同等の機能を持つための技術的課題 9ページより

このレポートによればSIMのセキュアエレメントを利用してコードを生成する、とある。そして、上記の図には書かれていないように、センターでの金額管理は行わず、端末個別でのやりとり、となっている。

また、DigiTallyは2017年に試験が行われた、としか書かれておらず、実際に使われた例としての記載ではない。


SIMにシールを貼るだけで電波の届かないところでも携帯で支払いできる技術」という記事があったけど、正直意味がわかんないので調べてみた。

公式ページ「DigiTally」→ https://www.cl.cam.ac.uk/~rja14/DigiTally/
概要紹介スライドpdf」→ https://www.cl.cam.ac.uk/~rja14/DigiTally/docs/DigiTally.pdf

・SIMの上に貼り付けるoverlay SIMとは何をするものなのか?
・どういう場合につかう想定なのか?
・どういう決済の仕組みになっているのか?


・SIMの上に貼り付けるoverlay SIMとは何をするものなのか?
digitally-1
しれっと出てきてる「EMV」は、Europay,MasterCard,VISAで決めたICチップ搭載のクレジットカードの規格のようです。
発展途上国でよく使われているGSM onlyのSIMはバージョンが古く、セキュリティに関する機構が搭載されていないので、SIMを交換しなくても、それを後から提供できるようにしたものが、今回のoverlay SIMではないかと思われます。
NFCのセキュアエレメントみたいなものの役割を果たしているようです。

 

で・・・よく読むと、overlay SIMが重要なのではなく、「SMAPs:Short Message Authentication Protocols」が重要なようです。

・どういう場合につかう想定なのか?
SMAPs(Short Message Authentication procotols)は、携帯電波が不安定でつながりにくく、また、データ通信量も増やせない環境で、如何にして信頼性を保ちつつ、決済を行うか、ということを考えて作られたプロトコルであるようです。

具体的には、SMS(ショートメッセージ)ベースでデータをやりとりすることで、ネットワークの不安定さを回避し、また、確実に相手に届ける、ということを実現するようです。
(GSMのみの途上国では、TCP/IPのデータ通信はパケット料が高額で、また不安定、ということ)

・どういう決済の仕組みになっているのか?
スライド記載の手順を元に日本語化してみました

(1) アリスはDigiTally口座(電子決済口座)に5ドルを入金する
(2) アリスと取引相手であるボブは、お互いの携帯電話を電話帳に登録する(?)
(3) アリスはボブから4ドルの品物を買いたいと伝えます
(4) ボブは自身の携帯の決済アプリに「4(ドル)」と入力し、「決済要求ボタン」を押します。
 (ボブ携帯からアプリがDigiTallyセンターにSMSで暗号化されている決済要求のメッセージを送る)
(5) ボブは、携帯の決済アプリに表示されている8桁の決済コード1をアリスに伝えます
(6) アリスは自身の携帯の決済アプリに「4(ドル)」と「8桁の決済コード1」を入力し、「決済承認ボタン」を押します。
 (アリス携帯からアプリがDigiTallyセンターにSMSで暗号化されている決済承認のメッセージを送る)
(7) アリスは、携帯の決済アプリに表示されている8桁の決済コード2をボブに伝えます
(8) ボブは自身の携帯の決済アプリに「8桁の決済コード2」を入力し、「決済完了ボタン」を押します。
 (ボブ携帯からアプリがDigiTallyセンターにSMSで暗号化されている決済完了のメッセージを送る)
(9) アリスのDigiTally口座から4ドルが引かれ1ドルになり、ボブのDigiTally口座に4ドルが足されます
(10) 決済完了ログが、アリスとボブの携帯に届きます。
 (DigiTallyセンターから、アリスとボブの携帯にSMSで決済完了ログを送る)

とても手動な感じで行うようです。
なお、上記のSMS送信ポイントは、想像が入ってます。

いろいろ文献を読むと、(4)と(6)と(8)のSMS送信に関しては遅延しても良いような実装、
つまりSMSの送信については携帯に搭載された決済アプリで再送制御を行うようです。

(4),(6),(8)のSMSがDigiTallyセンターに全部届いた時点で、決済が完了し(10)が行われるようなのですが
決済完了を確認する前に物品引き渡して、その後、決済不成立、ってことが発生しそうなんだけど
それをどうやって回避できるのかが読み取れなかった・・・

さらばJIAYUのスマホ?

しばらく前まで、結構いい感じのAndroidスマホを作っていた「JIAYU(佳域手机)」。
JIAYU S3以降、新機種がでないなぁ・・・と思っていたら、「トップページ」が「Funsso(方烁科技)」に飛ばされるようになりました。
Funssoは、光ファイバー用のSFPモジュールを販売しているメーカのようです。

スマホに関するページはFunssoにはありません。
唯一、JIAYU時代からある公式掲示板へのリンクがトップページに残されているだけです。

FussoとJIAYUの関係について、特にニュースや会社案内などでも説明されておらず、謎です。

ただ、1年以上新製品の話が出てないところもあわせて考えるとJIAYUのスマホ事業は終了した、と考えていいのではないかと思います

AndroidのバックアップソフトHeliumでデスクトップアプリを使わずadbコマンドだけで行う方法

Androidのバックアップソフト「Helium」はAndroid標準のバックアップ/リストア機能を流用する形で実現している。

ただ、Heliumの機能を使うためにはパソコンにHelium Desktopアプリをインストールし、そこから何かを行わせる必要がある。
Helium Desktop Installer and Android App」を見ると、いまは、Chromeアプリ、Windowsアプリ、MacOSXアプリ、Linuxアプリ、がある模様。

で、Linuxの配布内容を見てみると、中身は、adbコマンドとシェルスクリプトのみ。
これなら、アプリを入れず、adbコマンドだけで実現できるのでは?と実験してみる

BASE=$(dirname $0)
pkg=$($BASE/adb shell pm path com.koushikdutta.backup)
# apparently pm path appends a carriage return which screws
# up the class name in dalvikvm invocation
pkg=$(echo $pkg | cut -d : -f 2 | sed s/\\r//g)
echo $pkg
$BASE/adb shell << EOF CLASSPATH=$pkg app_process /system/bin com.koushikdutta.shellproxy.ShellRunner2 $@ & exit EOF

(1)adbコマンドで、Heliumアプリ(com.koushikdutta.backup)がインストールされているパス名調査
(2)そのパス名をCLASSPATH環境変数に指定して、コマンド実行

という感じ。
私の環境では
(1) /data/app/com.koushikdutta.backup-1/base.apk
(2)「CLASSPATH=/data/app/com.koushikdutta.backup-1/base.apk app_process /system/bin com.koushikdutta.shellproxy.ShellRunner2」
ということなので、

「adb shell」でAndroid端末にshellで入り、「CLASSPATH=/data/app/com.koushikdutta.backup-1/base.apk app_process /system/bin com.koushikdutta.shellproxy.ShellRunner2」を実行することで、アプリインストールの代替とすることができた。

GOLE2のクラウドファウンディングが開始されるも変態度が激下がり

5月に「中華ベンダGOLE社のGOLE1というタッチパネル付きミニPC」という記事でGOLE1のクラウドファウンディングを紹介しました。
これは無事出荷されました。

で・・・6月にはGOLE2を企画してるよ、との発言があり、どうなるかな?と思っていたところ
ついに、クラウドファウンディングが開始されました。

GOLE2, The real Mini PC with FHD wide-angle camera
gole2-1

・タッチパネルを廃止
・TVの横に置いて使うことを想定
・カメラを装備
・Intel Z8350搭載のWindows10モデルと、Allwinner A64搭載のAndroidモデルの2つを用意
・2.5インチHDD/SSD内蔵可能
・日本語マニュアル付き

Androidモデル・・・とはいっても、正確にはAOSPベースの「Phonenix OS」を採用(JideのRemixOSと似たようなもんです)

価格は
・Phoenix OSモデル(Orange): $69(100個限定),$79(200個限定),$89(300個限定),$99
・Windows10モデル(White or Black): $114(50個限定), $124(100個限定),$134(200個限定)

うーーーーん・・・・
それほど・・・コレといって・・・

GSMA規格準拠のスマホにNFC Type Fが搭載される・・・ということの出典は?

iPhone7の日本版でFelicaに対応した、という話で注目されているのは「2017年4月移行に発売されるGSMAのGCF認定を受けたNFC対応スマートフォンは、NFC Type Fも搭載される」という話。

日本語の出典を調べると、一番わかり安かったのがマイナビの下記記事だった。
iPhoneでモバイルSuicaが使えるようになる? – NFC対応スマートフォンにFeliCa搭載という流れ

GSMAの規格書である「TS.26 NFC Handset Requirement」と「TS.27 NFC Handset Test Book」に記載されている。
そこではNFC Forumの規格書を参照している、とのこと。

確認してみた。

1. 「GSMA」の「CATEGORY ARCHIVES: TERMINAL STEERING GROUP」に行く
2. 「TS.26 V9.0 NFC HANDSET REQUIREMENTS(2016/04/12)」と「TS.27 V9.0 NFC HANDSET TEST BOOK(2016/06/24)」を発見

3. TS26では、NFCに関する詳しいことはNFC Forumの文章に丸投げてる
gsma-001
 NFCForum-TS-Type-1-Tag_1.2 (or later)
 NFCForum-TS-Type-2-Tag_1.2 (or later)
 NFCForum-TS-Type-3-Tag_1.2 (or later)
 NFCForum-TS-Type-4-Tag_2.0 (or later)

また、「SGP.03 NFC UICC REQUIREMENTS SPECIFICATION V6.1(2016/04/04)」では特に書いてないような感じ

4. 「NFC Forum」の「NFC Forum Specification Architecture」へ行く

5. 「NFC Forum Technical Specifications」でNFC Forum Tag Type Technical Specificationsに関して確認
gsma-002
NFC ForumのTag Type 3がFelicaということが判明

ということでいいんだろうか?