[任務書+論文+PPT+源碼]基于Android與多媒體的英文學習APP的設計與實現(xiàn)
畢業(yè)設計（論文）任務書
第1頁
畢業(yè)設計（論文）題目：基于Android與多媒體技術的英文學習APP的設計與實現(xiàn)設計（論文）要求及原始數(shù)據(jù)（資料）：1．綜述國內外移動互聯(lián)現(xiàn)狀及前景；2．了解Android系統(tǒng)，理解Android應用程序的開發(fā)方法和步驟；3．分析該Android應用程序的模塊結構和主要算法；4．熟悉開發(fā)工具的使用，完成代碼編寫和測試；5．訓練檢索文獻資料和利用文獻資料的能力；6．訓練撰寫技術文檔與學位論文的能力。
第2頁
畢業(yè)設計（論文）主要內容：1．綜述國內外移動互聯(lián)網(wǎng)發(fā)展現(xiàn)狀及前景；2. 綜述分析“有道英語”的可行性及具體需求；3. 綜述“有道英語”APP的總體設計框架；4. 深入剖析“有道英語”APP詳細設計過程中所用的關鍵技術； 7. 測試“有道英語”APP的各個模塊的運行情況及功能模塊是否基本符合要求； 8. 分析并總結“有道英語”APP存在的不足之處，最后對指導老師表達致謝 學生應交出的設計文件（論文）：1．內容完整、層次清晰、敘述流暢、排版規(guī)范的畢業(yè)設計論文；2．包括畢業(yè)設計論文、源程序等內容在內的畢業(yè)設計電子文檔及其它相關材料
第3頁
主要參考文獻（資料）：商陸民，朱丹群，周然，邢海榮. 多功能電子詞典軟件設計[J]. 東南大學電子工程系,1995任楨.電子詞典的設計研究[J]. 華中科技大學,2003黃藝鋒，閆巧.基于Android平臺電子詞典的設計與實現(xiàn)[J].深圳大學計算機與軟件學院,2011朱婷婷，李惠.基于Android的應用軟件的綜述[J] .浙江師范大學數(shù)理信息學院,2011邵明博.基于智能手機的大學英語移動學習平臺研究[D]. 華中師范大學,2011尹京華,王華軍 .基于Android開發(fā)的數(shù)據(jù)存儲[J]. 成都理工大學信息科學與技術,2012劉銳.Android開發(fā)的性能優(yōu)化[D]. 新華網(wǎng)股有限公司,2009Serguei A.Mokhov?,Mashrur Mia.A UI Design Case Study and a Prototype of a Travel Search Engine.Scientific American,2010J.MANI BHARATHI, S.Hemalatha, V.AISHWARYA .Advancement in Mobile Communication using Android .International Journal of Computer Applications, 2010, Vol.1 (7)Code Home.Android-An Open Handest Alliance Project.Future Generation Computer Systems,2011
目 錄
1 緒論11
1.1 項目背景11
1.2 論文主要工作22
2 項目相關技術介紹與分析44
2.1 Android的發(fā)展和歷史44
2.2 Android體系結構55
2.2.1 Application（應用層）55
2.2.2 Application Framework（應用框架層）55
2.2.3 Libraries（系統(tǒng)運行庫層）55
2.2.4 Linux Kernel（Linux內核層）66
2.3 Android開發(fā)環(huán)境與工具66
2.3.1 搭建Android開發(fā)環(huán)境66
2.3.2 Android開發(fā)工具介紹1111
2.4 環(huán)境說明1111
2.4.1 編程環(huán)境1111
2.4.2 運行環(huán)境1111
3 項目可行性分析1212
3.1 可行性研究1212
3.1.1 技術可行性1212
3.1.2 經(jīng)濟可行性1212
3.1.3 操作可行性1212
4 項目需求分析與總體設計1313
4.1 需求分析1313
4.1.1 功能性需求分析1313
4.1.2 非功能性需求分析1313
4.2 系統(tǒng)總體設計及模塊劃分1313
4.2.1 模塊劃分1313
4.2.2 系統(tǒng)操作流程圖1414
4.3 數(shù)據(jù)庫設計及數(shù)據(jù)操作1515
4.3.1 數(shù)據(jù)庫概念設計1616
4.3.2 數(shù)據(jù)庫邏輯設計1717
4.3.3 數(shù)據(jù)庫的創(chuàng)建1717
4.3.4 數(shù)據(jù)庫的操作1717
4.3.5 數(shù)據(jù)的查看1717
5 系統(tǒng)的詳細設計與實現(xiàn)1919
5.1 系統(tǒng)主界面的設計1919
5.2 查詢模塊詳細設計：2020
5.2.1 調用有道翻譯API20API20API20
5.2.2 Json數(shù)據(jù)解析2121
5.3 發(fā)現(xiàn)模塊詳細設計2222
5.4 我的模塊2727
6 系統(tǒng)的測試2929
6.1 程序的測試2929
6.1.1 歡迎界面3030
6.1.2 主界面3131
6.1.3 “詞典”以及“翻譯”模塊3232
6.1.4 “發(fā)現(xiàn)”模塊測試3636
6.1.5 “我的”模塊測試3737
6.2 測試結果說明3838
致謝4040
參考文獻4141
外文文獻4242
1 緒論
1.1 項目背景
隨著全球化地球村時代的到來，英語成為全球化的基礎交流語言，想要走出國門走向世界，英語成為每一位追夢人的必跨門檻。它對于希望擁有更寬視野的人來說，必不可少社會生活的信息化和經(jīng)濟的全球化，使英語的重要性日益突出。英語作為最重要的信息載體之一，已成為人類生活各個領域中使用最廣泛的語言，英語能力已成為一種必備技能。學生若能學得一種外語能力，就能幫他打開進入另一個世界的學習之門，最后達成多元學習與價值的目標。從全世界來看，說英語的人數(shù)已經(jīng)超過了任何語言的人數(shù)，英語在45個國家是官方語言，世界三分之一的人口講英語，75%的電視節(jié)目是英語，四分之三的郵件是用英語書寫，電腦鍵盤是英語鍵盤，任何一個會議敢號稱是國際會議，其會議語言一定要用英語。此外，外貿(mào)行業(yè)也把英語作為通用語言，外貿(mào)交往、國際禮儀、書信函電、進出口文件、還有銀行文件語言等，統(tǒng)統(tǒng)以英語作為標準通用語言。大多數(shù)國家的高等學府，大學院校，都開設英語語言文學專業(yè)，僅在中國，就有數(shù)百所大學設有英語專業(yè)或英語相關專業(yè)。電腦和互聯(lián)網(wǎng)也是建立在英語的基礎上，這個行業(yè)的語言，就是英語，另外，在醫(yī)學領域、建筑領域、文學領域，都與英語有極大的關聯(lián)。
在Twitter與Facebook出現(xiàn)之前，當Google還只是一個想法的時候，手機只是足夠小的便攜式電話，能夠放在一個公文包中，電池足夠用上幾個小時，雖然沒有多余的功能，但是手機確實使人們可以不通過物理通信線路就能自由通信。
現(xiàn)在、小巧、時尚而且功能強大的手機已經(jīng)相當普及并且不可或缺。硬件的發(fā)展使手機在擁有更大更亮的屏幕和越來越多的外圍設備的同時也變的更加小巧和高效。
作為一款Linux內核的操作系統(tǒng)，android系統(tǒng)因其移植性、跨平臺性以及開放性被廣大移動終端廣泛使用。它涵蓋移動信息設備工作所需的全部軟件，包括操作系統(tǒng)、用戶界面和應用程序。Android系統(tǒng)不但可以應用于智能手機，在平板電腦市場也在急速擴張。Android正在逐漸成為目前移動信息設備應用程序開發(fā)的最主要的平臺。
移動互聯(lián)網(wǎng)(MobileInternet, 簡稱MI)是一種通過智能移動終端，采用移動無線通信方式獲取業(yè)務和服務的新興業(yè)務，包含終端、軟件和應用三個層面。終端層包括智能手機、平板電腦、電子書、MID等；軟件包括操作系統(tǒng)、中間件、數(shù)據(jù)庫和安全軟件等。應用層包括休閑娛樂類、工具媒體類、商務財經(jīng)類等不同應用與服務。隨著技術和產(chǎn)業(yè)的發(fā)展，未來，LTE(長期演進，4G通信技術標準之一)和NFC(近場通信，移動支付的支撐技術)等網(wǎng)絡傳輸層關鍵技術也將被納入移動互聯(lián)網(wǎng)的范疇之內。
移動互聯(lián)網(wǎng)的多媒體信息中的應用。隨著科技的進步，多媒體服務的移動用戶將成為主要趨勢，移動通信的發(fā)展在未來的十年。無線技術仍然在高速發(fā)展，未來空中接口的帶寬不斷增加，手持終端的功能將不斷完善和提高，各種移動應用的發(fā)展開辟了廣闊的空間。第二代數(shù)字移動通信系統(tǒng)發(fā)展到第三代移動通信系統(tǒng)是必然的趨勢。移動終端用戶對移動數(shù)據(jù)業(yè)務的強烈需求，和運營商也要提供更多的增值服務的設備。移動互聯(lián)網(wǎng)的發(fā)展，需要滿足統(tǒng)一的IP核心網(wǎng)的戰(zhàn)略要求，為移動數(shù)據(jù)通信的需要移動的主要移動互聯(lián)網(wǎng)市場。人們可以使用一些強大的掌上電腦，掌上電腦和筆記本電腦進行大量的數(shù)據(jù)處理和顯示，真正滿足用戶的移動計算應用的需求。
4G互聯(lián)網(wǎng)時代下，移動應用越來越多，Android 4.2.2更新包于2013年2月11日發(fā)布，未來采用Android系統(tǒng)手機越來越多。不僅僅在于手機，在任何移動設備上，都可以采用Android開發(fā)移植到終端設備上，例如電視、冰箱、空調、洗衣機等。將這些設備計入互聯(lián)網(wǎng)，我們可以通過手機實時知道各個設備的狀態(tài)，也可以控制它們工作。總之，Android 將帶給我們更加智能、便捷、現(xiàn)代的生活。從而，Android應用的開發(fā)，
將會越來越龐大，需求將會越來越豐富。
1.2 論文主要工作
本論文的內容主要包括摘要、目錄、緒論、Android簡介及編程環(huán)境與工具、有道英語可行性分析、有道英語需求分析、有道英語APP的總體設計、有道英語APP的詳細設計、有道英語APP的測試、結束語、致謝和參考文獻幾部分內容。
其中，緒論部分主要介紹了國內外移動互聯(lián)的發(fā)展情況、課題實現(xiàn)的背景及意義和本論文的主要結構；Android簡介及編程環(huán)境與工具部分主要介紹了編程環(huán)境的搭建，開發(fā)工具的使用；有道英語APP分析部分主要說明了該項目的可行性分析、需求分析；有道英語APP的總體設計部分主要介紹了軟件每個模塊的設計框架以及每個模塊子模塊的設計框架；有道英語APP的具體實現(xiàn)部分即詳細設計部分，主要敘述了軟件的具體實現(xiàn)思路、邏輯和部分主要截圖及源代碼；有道英語APP的測試部分主要描述了軟件最后實現(xiàn)的效果是否滿足軟件設計之初的基本需求。
1.3 論文脈絡
圖1-1
2 項目相關技術介紹與分析
2.1 Android的發(fā)展和歷史
Android是以Linux為基礎的開放源碼的操作系統(tǒng)，主要應用于便攜設備。最開始由Andy Rubin開發(fā)，主要支持手機。2005年由Google收購注資，并組建開放手機聯(lián)盟開發(fā)一戶，其逐漸擴展至平板電腦及其他領域上。2012年2月數(shù)據(jù)顯示，Android占據(jù)全球智能手機操作系統(tǒng)市場52.5%的份額，中國市場占有率為68.4%。
Android系統(tǒng)版本發(fā)布時間如表2-1所示。
表2-1 Android版本發(fā)布時間
序號時間事件12003年10月Andy Rubin等人創(chuàng)建Android公司，并組建Android團隊22005年8月17日Google收購了成立僅22個月的高科技企業(yè)Android32007年11月5日Google公司正式向外界展示Android操作系統(tǒng)42008年9月22日Google正式對外發(fā)布第一款Android手機（HTC G1）52008年9月23日Android1.0正式發(fā)布62009年4月30日Android1.5正式發(fā)布72009年9月15日Android1.6正式發(fā)布82010年5月20日Android2.2版本軟件開發(fā)工具包發(fā)布92010年12月7日Android2.3版本軟件開發(fā)工具包發(fā)布102011年2月2日Android3.0正式發(fā)布112011年2月3日Google發(fā)布了專用于平板電腦的Android3.0蜂巢系統(tǒng)122011年10月19日Google正式發(fā)布Android4.0操作系統(tǒng)132012年6月28日Google正式發(fā)布Android4.1操作系統(tǒng)142012年10月30日Google正式發(fā)布Android4.2操作系統(tǒng)152013年7月25日Google正式發(fā)布Android4.3操作系統(tǒng)162013年9月4日Google正式發(fā)布Android4.4操作系統(tǒng)
2.2 Android體系結構
在Android操作系統(tǒng)中，將體系結構劃分為4層：Application（應用層）、Application Framework（應用框架層）、Libraries（系統(tǒng)運行庫層）以及Linux Kernel（Linux內核層）。Android體系結構如圖2-1所示：
圖2-1 Android體系結構圖
2.2.1 Application（應用層）
應用層是使用Java語言進行開發(fā)的一些應用程序，如地圖軟件、聯(lián)系人管理、E-mail連接、瀏覽器等都屬于應用層上運行的程序，許多開發(fā)出來的程序（如音樂播放器、通訊錄等）也都是運行在應用層上的。[3]該軟件（TYUT掌中行）也是運行在此層上的。
2.2.2 Application Framework（應用框架層）
應用框架層主要是Google發(fā)布的一些操作支持的類庫（API框架），開發(fā)人員可以使用這些類庫方便地進行程序開發(fā)，但是在開發(fā)時必須遵守框架的開發(fā)原則。而在應用框架層中也包含了眾多的組件。[3]
2.2.3 Libraries（系統(tǒng)運行庫層）
當使用Android框架層進行開發(fā)時，Android操作系統(tǒng)會自動使用一些C/C++的庫文件來支持所使用的各個組件，使其可以更好地為程序服務。[3]
2.2.4 Linux Kernel（Linux內核層）
Android操作系統(tǒng)主要基于Linux2.6內核，程序的安全性、驅動程序、進程管理等都由Linux內核所提供。[3]
2.3 Android開發(fā)環(huán)境與工具
2.3.1 搭建Android開發(fā)環(huán)境
1、下載、安裝JDK及測試JDK是否成功安裝
下載網(wǎng)址：http://www.oracle.com/technetwork/java/javase/downloads/index.html
下載界面如圖2-2所示。
圖2-2 JDK下載頁面
我的JDK安裝路徑，如圖2-3所示。
圖2-3 JDK安裝路徑
JDK環(huán)境變量配置，如圖2-4所示。
圖2-4 JDK環(huán)境變量設置
檢查JDK是否安裝成功，在cmd下輸入命令javac，如果出現(xiàn)如圖2-5所示情況則為安裝成功。
圖2-5 JDK安裝成功界面
下載并安裝Eclipse
下載網(wǎng)址：http://www.eclipse.org/downloads/，如圖2-6所示。下載完畢后直接解壓，無需安裝。
圖2-6 eclipse下載界面
下載Android SDK
下載網(wǎng)址：http://developer.android.com/sdk/index.html，登錄該網(wǎng)址將會出現(xiàn)如圖2-7所示網(wǎng)頁，點擊Download the SDK選擇對應版本下載解壓即可。
圖2-7 SDK下載界面
安裝Android開發(fā)插件
(1)打開Eclipse, 在菜單欄上選擇 Help->Install New SoftWare 將會出現(xiàn)如圖2-8所示界面。
圖2-8 安裝插件第一步
點擊 Add按鈕,出現(xiàn)如圖2-9所示界面。其中，Name可以自己設定，此處設為“Android”，Location中輸入網(wǎng)址：http://dl-ssl.google.com/android/eclipse/。
圖2-9 安裝插件第二步
點擊如圖2-9所示界面OK按鈕，出現(xiàn)如圖2-10所示界面。
圖2-10 安裝插件第三步
點擊如圖2-10所示界面 Next按鈕，出現(xiàn)如圖2-11所示界面。
圖2-11 安裝插件第四步
點擊如圖2-11所示界面Next按鈕，出現(xiàn)如圖2-12所示界面。
圖2-12 安裝插件第五步
選擇I accept the terms of the license agreements 點擊如圖2-12所示界面Next按鈕,進入安裝插件界面，如圖2-13所示。
圖2-13 安裝插件第六步 圖2-14 安裝插件第七步
安裝完成后，提示重新啟動Eclipse，點擊如圖2-14所示界面Yes按鈕。
配置Android SDK
點擊Eclipse菜單window->preferences,進入如圖2-15所示界面。選擇SDK所在目錄。點擊OK。
圖2-15 配置SDK
通過以上步驟，本文作者就把Android開發(fā)環(huán)境搭建好了。
2.3.2 Android開發(fā)工具介紹
任何軟件的開發(fā)都離不開強大的開發(fā)工具，同理Android開發(fā)也有自己的開發(fā)工具。以下內容將簡要介紹Android的開發(fā)工具。
1.JDK簡介
JDK(Java Development Kit)是Sun Micro Systems針對Java開發(fā)員的產(chǎn)品。自從Java推出以來，JDK已經(jīng)成為使用最為廣泛的Java SDK。JDK 是整個Java的核心，包括了Java運行環(huán)境、Java工具和Java基礎類庫。
2.Eclipse簡介
Eclipse 是一種基于 Java 的可擴展開源開發(fā)平臺。其僅僅是一個框架和一組服務，用于通過插件組件構建開發(fā)環(huán)境。另外，Eclipse 附帶了一個標準的插件集JDT（Java Development Tools），Eclipse 還包括插件開發(fā)環(huán)境PDE（Plug-in Development Environment），這個組件主要為希望擴展 Eclipse 的軟件開發(fā)人員而設計。
3.ADT簡介
ADT(Android Development Tools)是Android開發(fā)所用工具是Eclipse編譯IDE環(huán)境中的工具，安裝ADT，可以為Android開發(fā)提供便利。
4.SDK簡介
SDK(Software Development Kit)是一些被軟件工程師用于為特定的軟件包、軟件框架、硬件平臺、操作系統(tǒng)等建立應用軟件的開發(fā)工具的集合。
2.4 環(huán)境說明
以下內容將說明本文作者開發(fā)該軟件所使用的編程環(huán)境以及該軟件運行的平臺。
2.4.1 編程環(huán)境
本文作者用Eclipse和Android SDK（Android2.2）作為編程環(huán)境，在軟件編寫初期使用模擬器進行測試，后期軟件逐步成熟后使用真機進行測試。
2.4.2 運行環(huán)境
軟件運行在操作系統(tǒng)為Android2.2以上版本的手機。基本滿足Android2.2系統(tǒng)以
上的各種型號手機（主要指屏幕適配方面）。
3 項目可行性分析
3.1 可行性研究
3.1.1 技術可行性
技術可行性分析主要分析現(xiàn)有技術條件能否順利完成開發(fā)工作，硬、軟件配置能否滿足開發(fā)者需要等。對于Android開發(fā)，Google公司提供了良好的開發(fā)集成工具，且本文作者大學所學專業(yè)為軟件工程移動互聯(lián)網(wǎng)方向，對Android手機應用有一段時間的研究與開發(fā)經(jīng)驗，并且熟悉Java語言。所以該軟件在開發(fā)技術這方面是可行的。
3.1.2 經(jīng)濟可行性
本軟件開發(fā)所使用的eclipse集成環(huán)境是免費軟件，這很大程度上節(jié)省了開發(fā)成本。并且在后期的實際使用過程中，太原理工大學良好的校園無線覆蓋為師生使用該軟件過程中需要網(wǎng)絡連接提供很大便利。所以該軟件在經(jīng)濟可行性方面也是滿足的。
3.1.3 操作可行性
該軟件的安裝使用和Android應用市場的大多數(shù)應用軟件類似，所以大多數(shù)用戶都能夠在不需進行指導的前提下方便使用該軟件，并且軟件系統(tǒng)里面都有良好的提示功能。因此從操作可行性的角度來衡量，該軟件的開發(fā)是可行的。
綜上可知，該軟件系統(tǒng)在技術、經(jīng)濟和操作上都是可行的，滿足可行性分析的要求，因此可以開發(fā)此軟件系統(tǒng)。
4 項目需求分析與總體設計
4.1 需求分析
4.1.1 功能性需求分析
通過一段時間的調研，根據(jù)反饋回來的意見，有道英語的功能需求大致定為：
a、查詞并實現(xiàn)添加到生詞本
b、翻譯語句
c、四六級音頻學習
4.1.2 非功能性需求分析
非功能需求有：
a、低資源消耗
手機設備CPU及內存資源相對有限，要求程序節(jié)省單詞查詢和翻譯時所用時間以及對CPU的占用，從而節(jié)省對手機硬件資源的占用，提高程序運行的流暢度。
b、易用性
易用性是與一組規(guī)定或者潛在的用戶為使用其軟件所需做的努力和對這樣的使用所作的評價有關的一組屬性。具體包括：
? 易理解性：與用戶為人質邏輯概念即其應用范圍所花的努力有關的軟件屬性。
? 易學習性：與用戶為學習軟件應用所花的努力有關的軟件屬性。
? 易操作性：與用戶為操作和運行控制所花的努力有關的軟件屬性。如帶首字母篩選功能的下拉列表等。
4.2 系統(tǒng)總體設計及模塊劃分
4.2.1 模塊劃分
根據(jù)功能性需求，系統(tǒng)模塊劃分為：詞典模塊、翻譯模塊、發(fā)現(xiàn)模塊、我的模塊。對應的模塊圖如圖4-1:
圖4-1 系統(tǒng)模塊圖
4.2.2 系統(tǒng)操作流程圖
本系統(tǒng)在預設的操作過程為：點擊APP通過響應界面后。
第一：進入查詢單詞的界面，詞典功能的實現(xiàn)是通過調用有道api進行聯(lián)網(wǎng)查詢，查詢出的單詞可以進行單獨備份，即：錄入單詞本中；
第二，可以通過底部的切換卡進行，切換至翻譯界面，然后可以輸入對應的中英文句子，同樣通過調用有道api進行聯(lián)網(wǎng)實現(xiàn)翻譯；
第三，通過切換卡將界面切換至發(fā)現(xiàn)模塊，可以進行四六級音頻的學習以及四六級?？嫉拿跃?；
第四，通過切換卡將界面切換至我的模塊，可以進行之前在單詞查詢中備份的單詞進行查看，并且可以通過點擊單詞實現(xiàn)再次跳轉到詞典界面實現(xiàn)二次查詢。
該軟件的操作流程圖如圖4-2所示：
圖4-2 系統(tǒng)操作流程圖
4.3 數(shù)據(jù)庫設計及數(shù)據(jù)操作
SQLite，是一款輕型的數(shù)據(jù)庫，是遵守ACID的關系型數(shù)據(jù)庫管理系統(tǒng)，它的設計目標是嵌入式的，而且目前已經(jīng)在很多嵌入式產(chǎn)品中使用了它，它占用資源非常的低，在嵌入式設備中，可能只需要幾百K的內存就夠了。它能夠支持Windows/Linux/Unix等等主流的操作系統(tǒng)，同時能夠跟很多程序語言相結合，比如 Tcl、C#、PHP、Java等，還有ODBC接口，同樣比起Mysql、PostgreSQL這兩款開源世界著名的數(shù)據(jù)庫管理系統(tǒng)來講，它的處理速度比他們都快。
SQLite相關知識點：
SQLiteDatabase
一個SQLiteDatabase的實例代表一個SQLite的數(shù)據(jù)庫，通過SQLite實例的一些方法，我們可以執(zhí)行SQL語句，進行對數(shù)據(jù)庫的增刪改查。數(shù)據(jù)庫對于一個應用來說是私有的，并且在一個應用當中，名字也是唯一的。
（2）SQLiteOpenHelper
這是一個抽象類。對于SQLiteOpenHelper我們通常需要繼承它，并實現(xiàn)它里面的三個函數(shù)。
1)onCreate
在數(shù)據(jù)庫第一次生成時會調用這個方法，一般我們在這個方法里生成數(shù)據(jù)庫表。
2）onUpgrade
當數(shù)據(jù)庫需要升級的時候，Android系統(tǒng)會自動調用這個方法，一般我們在這個方法里面刪除數(shù)據(jù)庫表，并建立新的數(shù)據(jù)庫表。并且還可以根據(jù)應用需求進行其他操作。
3）onOpen
這是當打開數(shù)據(jù)庫是的回調函數(shù)，一般不會用到。
本系統(tǒng)采用的是sqlite數(shù)據(jù)庫，sqlite數(shù)據(jù)庫是Android自帶的小型數(shù)據(jù)庫，可以將少量的數(shù)據(jù)存放在該數(shù)據(jù)庫中。針對不同的用戶的生詞是不同的，可以很方便的將生詞導入到數(shù)據(jù)庫中，也可以很方便的將單詞從數(shù)據(jù)庫中刪除。將此軟件中的數(shù)據(jù)表的關系設計如下：
4.3.1 數(shù)據(jù)庫概念設計
根據(jù)需求分析的結果，將本APP的數(shù)據(jù)庫設計如下：
圖4-3 生詞表的設計
圖4-4 翻譯句子表的設計
圖4-5歷史詞匯表的設計
4.3.2 數(shù)據(jù)庫邏輯設計
本APP維護了3個表，并且由于為了實現(xiàn)簡便，并沒有涉及到3個表之間的交互及數(shù)據(jù)共享，因此，得到的表的結構及屬性分別為：
history(_id ,query, translation ,uk ,us,explain)
sentence(_id ,JUZI ,YISI )
history(_id , query, translation, uk, us explains );
4.3.3 數(shù)據(jù)庫的創(chuàng)建
Android 提供了標準的數(shù)據(jù)庫創(chuàng)建方式。繼承SQLiteOpenHelper ,實現(xiàn)onCreate() 和 onUpgrade() 兩個方法，有個好處就是便于數(shù)據(jù)庫版本的升級，連接數(shù)據(jù)庫的算法見程序清單。數(shù)據(jù)庫如果創(chuàng)建不成功則拋出FIleNotFoundException異常。
4.3.4 數(shù)據(jù)庫的操作
Android對SQLite數(shù)據(jù)庫的操作主要有插入、刪除、查詢操作。但是前置條件是必須打開數(shù)據(jù)庫。在這里打開數(shù)據(jù)庫用的主要的方法是openForReadable()和openForWriteable(),打開數(shù)據(jù)之后才能進行相關的操作，其中插入單詞的方法是insert(),刪除單詞的方法是delete()。其詳細代碼見程序清單。注意：在操作完了數(shù)據(jù)庫之后，需要對資源進行釋放，這里就是對數(shù)據(jù)庫資源進行關閉，關閉數(shù)據(jù)庫的方法是close()。
4.3.5 數(shù)據(jù)的查看
Android中程序是利用Cursor游標類指向數(shù)據(jù)表中的某一項，然后進行查詢數(shù)據(jù)，用Log日志顯示出來。查詢時用的方法是數(shù)據(jù)庫本身的查詢方法query(),需要注意的是這個方法比較復雜，他有8個參數(shù)，因為它將一個完整的SQL語句拆成了若干個部分：
第一個參數(shù)table：表名，相當于SQL的from后面的部分。在此還要注意
如果和多表聯(lián)合查詢時，就用逗號將兩個表名分開，拼成一個字符串的table值。
第二個參數(shù)是columns，要查詢出來的列名。相當于SQL的select后面的部分。
第三個參數(shù)是selection，查詢的條件，相當于SQL的where后面的部分，在這個語句中允許使用“？”，也就是說這個用法和JDBC中的PreparedStatement的用法相似。
第四個參數(shù)selectionArgs，對應于selection的值，selection有幾個問號，這里就得用幾值。
第五個參數(shù)groupBy，相當于SQL的group by后面的部分。
第六個參數(shù)having，相當于SQL的having后面的部分。
第七個參數(shù)orderBy，相當于SQL的order by后面的部分，如果是倒序，或者是聯(lián)合排序，可以寫成類似這樣：String orderBy = “id desc,name”。
第八個參數(shù)limit，指定的結果集的大小，它和Mysql的limit用法不太一樣，Mysql可以指定從多少行開始之后取多少條，例如，“l(fā)imit 100,10”，但是這里只支持一個數(shù)值。
5 系統(tǒng)的詳細設計與實現(xiàn)
5.1 系統(tǒng)主界面的設計
本項目的主界面的菜單欄的底部位置是通過TabHost這個組件來實現(xiàn)的，首先在activity_translate.xml布局文件中聲明，切換卡則通過TabWidget實現(xiàn)，而切換卡的背景更換則是通過chat_tab_selector.xml的設置來實現(xiàn)，chat_tab_selector.xml的代碼如下：
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@drawable/ju" android:state_focused="true"/>
<item android:drawable="@drawable/dise" android:state_selected="true"/>
<item android:drawable="@drawable/dise" android:state_pressed="true"/>
<item android:drawable="@drawable/ju"/>
</selector>
制定完主頁面布局后，在src/com.example.translate下的TranslateActivity文件中OnCreate（OnCreate方法是用來初始化Activity實例對象的）中調用布局，另外因為本activity在創(chuàng)建時沒有繼承TabActivity，因此必須在得到tabHost之后，添加標簽之前調用tabHost.setup()，到現(xiàn)在為止頂部菜單欄的布局已經(jīng)基本完成，但現(xiàn)在里面所對應的內容還是空的。所以就需要在這里給tabHost中添加tab內容，以第一格的tab為例，先是通過Intent的方式新建個intent1，用來實現(xiàn)頁面的跳轉的方法，然后動態(tài)用createTab()的方法添加對應切換卡內容以及跳轉對象。具體代碼如下：
public class TranslateActivity extends ActivityGroup {
private TabHost tabHost = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_translate);
tabHost = (TabHost) findViewById(R.id.trainTab);
// 如果不是繼承TabActivity，則必須在得到tabHost之后，添加標簽之前調用tabHost.setup()
tabHost.setup(this.getLocalActivityManager());
Intent intent1 = new Intent(this, WordActivity.class);
Intent intent2 = new Intent(this, ContentActivity.class);
Intent intent3 = new Intent(this, FxActivity.class);
Intent intent4 = new Intent(this, SCActivity.class);
createTab("詞典", intent1.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP));
// 切換時刷新Activity
createTab("翻譯", intent2);
createTab("發(fā)現(xiàn)", intent3);
// 切換時刷新Activity
createTab("我的", intent4.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP));
tabHost.setCurrentTab(0);
}
在上述思路下我們的詳細的效果圖如下：
圖5-1 系統(tǒng)主界面
5.2 查詢模塊詳細設計：
5.2.1 調用有道翻譯API
有道翻譯API，為廣大開發(fā)者提供開放接口，從而降低語言理解與應用門檻。依靠有道翻譯網(wǎng)絡數(shù)據(jù)挖掘和統(tǒng)計機器翻譯技術實力做基礎，可以更加快捷的完成項目，具體代碼如下：
try {
urlStr =
"http://fanyi.youdao.com/openapi.do?keyfrom=justTec&key=1249502330&type=data&doctype=json&version=1.1&q=" +URLEncoder.encode(word, "utf8");
} catch (UnsupportedEncodingException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
5.2.2 Json數(shù)據(jù)解析
在本系統(tǒng)中查詞和翻譯調用有道接口，通過HTTP協(xié)議回傳給設備，返回來的數(shù)據(jù)為標準的Json格式，再通過Json解析顯示到對應的UI上。具體代碼如下：
try?{
String jsonData = "";
// 向指定的URL發(fā)送Http請求
HttpResponse response = httpClient.execute(new?HttpGet(urlStr));
// 取得服務器返回的響應
HttpEntity entity = response.getEntity();
BufferedReader bufferedReader =?new?BufferedReader(new?InputStreamReader(entity.getContent()));
String line = "";
while?((line = bufferedReader.readLine()) !=?null) {
jsonData = jsonData + line;
}
word =?new?Word();
JSONObject jsonObject =?new?JSONObject(jsonData);
word.setQuery(query);
word.setTranslation(jsonObject.getJSONArray("translation").getString(0));
JSONObject basic = jsonObject.getJSONObject("basic");
// 音標
word.setUk(basic.getString("uk-phonetic").trim());
word.setUs(basic.getString("us-phonetic").trim());
// 返回json數(shù)組
String otherString = "";
JSONArray otherArray = basic.getJSONArray("explains");
for?(int?i = 0; i < otherArray.length(); i++) {
otherString += ";" + otherArray.getString(i);
}
word.setExplains(otherString.substring(1));
}?catch?(Exception e) {
}
模塊效果截圖如下：
圖5-2 模塊界面 圖5-3 中文查詞
5.3 發(fā)現(xiàn)模塊詳細設計
發(fā)現(xiàn)模塊意在提升大學生的空閑時間利用率，因此結合大部分同學們的需求，加入了四六級聽力音頻以及四六級作文中經(jīng)常被引用的諺語名言，最后還加入了關于我們，用來申明一些系統(tǒng)的信息：
四六級聽力音頻，主要是利用了Android自帶的mediaplayer來進行定制實現(xiàn)，首先將所要播放的音頻放入到資源raw文件夾中，然后申明出一個mediaplayer對象，通過其start(),stop()和pause()三個方法進行對應的音頻的播放，停止和暫停。具體代碼如下：
布局代碼：
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:paddingBottom="@dimen/activity_vertical_margin"
android:paddingLeft="@dimen/activity_horizontal_margin"
android:paddingRight="@dimen/activity_horizontal_margin"
android:paddingTop="@dimen/activity_vertical_margin"
android:background="@drawable/mao"
tools:context=".Cet41Activity" >
<Button
android:id="@+id/pauseBtn"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentLeft="true"
android:layout_alignParentTop="true"
android:layout_marginLeft="21dp"
android:layout_marginTop="122dp"
android:text="暫停" />
<Button
android:id="@+id/playBtn"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignLeft="@+id/pauseBtn"
android:layout_alignParentTop="true"
android:layout_marginTop="28dp"
android:text="播放" />
<Button
android:id="@+id/stopBtn"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignLeft="@+id/pauseBtn"
android:layout_below="@+id/pauseBtn"
android:layout_marginTop="46dp"
android:text="停止" />
</RelativeLayout>
對應實現(xiàn)代碼：
player=MediaPlayer.create(this,R.raw.cet4);
playBtn.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
// TODO Auto-generated method stub
player.start();
playBtn.setEnabled(false);
stopBtn.setEnabled(true);
pauseBtn.setEnabled(true);
}
});
實現(xiàn)效果如下：
圖5-4 音頻課堂 圖5-5 音頻播放
b、諺語名言模塊，將四六級考試中常用到的100句諺語名言整理成Excel文件，然后把Excle表中的100個英文語句與翻譯寫入數(shù)據(jù)庫，然后通過隨機函數(shù)Random()在每次啟動程序從100個句子隨機顯示一句及其翻譯。具體實現(xiàn)該模塊的重點代碼如下：
1）將Excle表中的句子導入數(shù)據(jù)庫表的代碼：
try {
// 讀取Excel，導入到數(shù)據(jù)庫
InputStream in = this.getClass().getClassLoader().getResourceAsStream
("com/example/translate/db/juzi.xls");
// 創(chuàng)建工作簿
HSSFWorkbook workBook = new HSSFWorkbook(in);
HSSFSheet sheet = workBook.getSheet("Sheet1");
int rows = sheet.getPhysicalNumberOfRows();
if (rows > 0) {
for (int j = 0; j < rows; j++) {
// 行循環(huán)
HSSFRow row = sheet.getRow(j);
if (row != null) {
HSS
參考文獻
商陸民，朱丹群，周然，邢海榮. 多功能電子詞典軟件設計[J]. 東南大學電子工程系,1995
任楨.電子詞典的設計研究[J]. 華中科技大學,2003
黃藝鋒，閆巧.基于Android平臺電子詞典的設計與實現(xiàn)[J].深圳大學計算機與軟件學院,2011
朱婷婷，李惠.基于Android的應用軟件的綜述[J] .浙江師范大學數(shù)理信息學院,2011
邵明博.基于智能手機的大學英語移動學習平臺研究[D]. 華中師范大學,2011
尹京華,王華軍 .基于Android開發(fā)的數(shù)據(jù)存儲[J]. 成都理工大學信息科學與技術,2012
劉銳.Android開發(fā)的性能優(yōu)化[D]. 新華網(wǎng)股有限公司,2009
Serguei A.Mokhov,Mashrur Mia.A UI Design Case Study and a Prototype of a Travel Search Engine.Scientific American,2010
J.MANI BHARATHI,?S.Hemalatha,?V.AISHWARYA?.Advancement in Mobile Communication using Android .International Journal of Computer Applications, 2010, Vol.1 (7)
[10]Code Home.Android-An Open Handest Alliance Project.Future Generation Computer Systems,2011
外文文獻
An Enhanced Dragonfly Key Exchange?Protocol against Offline
Dictionary Attack
Abstract
Dragonfly is Password Authenticated Key Exchange protocol that uses a shared session key to authenticate parties based on pre-shared secret password. It was claimed that this protocol was secure against off-line dictionary attack, but a new research has proved its vulnerability to off-line dictionary attack and proving step was applied by using “Patched Protocol” which was based on public key validation. Unfortunately, this step caused a raise in the computation cost, which made this protocol less appealing than its competitors. We proposed an alternate enhancement to keep this protocol secure without any extra computation cost that was known as “Enhanced Dragonfly”.This solution based on two-pre-shared secret passwords instead of one and the rounds between parties had compressed into two rounds instead of four. We prove that the enhanced-Dragonfly protocol is secure against off-line dictionary attacks by analyzing its security properties using the Scyther tool. A simulation was developed to measure the execution time of the enhanced protocol,which was found to be much less than the execution time of patched Dragonfly. The off-line dictionary attack time is consumed for few days if the dictionary size is 10,000. According to this, the use of the enhanced Dragonfly is more efficient than the patched Dragonfly.
Keywords:Password Authenticated Key Exchange (PAKE), Original Dragonfly,
Patched Dragonfly, Enhanced Dragonfly, Two-Pre-Shared Password
Introduction
Nowadays, information is increasing at a faster rate and it needs to be secured when exchanging it over insecure networks. The most efficient way to secure this information is Cryptology which is the science of building and analyzing secret code. It consists of cryptography and cryptanalysis. Cryptography is the science that builds secret codes and cryptanalysis is the science that analyzes those codes [1]. There are two types of cryptography:
Symmetric and Asymmetric key cryptography. Symmetric key cryptography has a shared key that is used by the sender and receiver in encryption and decryption processes, while Asymmetric key cryptography has a public key which is used in encryption processes and private key which is used in decryption processes .
One of the symmetric cryptography protocols is key exchange protocol, which allows two parties who share non-secret information to compute a shared key via public communication. Authenticated Key Exchange (AKE) is a symmetric protocol that not only allows parties to compute the shared key but also ensures the identity of the parties where a party can compute a shared key only if he/she is the one who claims to be [3]. Another example of symmetric protocols is the Two-party Password-based Authenticated Key Exchange (2PAKE) protocol that permits two parties to generate a session key based on a pre-shared password and authenticates each other[4]. In general, PAKE protocols are exposed to different types of attacks, mainly passive and active attacks. Passive attacks are difficult to detect and are used to get information that is sent between parties without modifying the information or harming the resources. Active attacks enable the attacker to modify the encrypted message orchange the meaning of the decrypted message by creating false streams [5]. However, the most complicated type of attack is the dictionary attack regardless of whether it is offline or online. Offline dictionary attack enables the attacker to record information from successful execution of the protocol by eavesdropping on the communication between parties. Then the attacker goes offline to find the required password by trying all passwords and choosing the correct password depending on the recorded information. The interaction with the server is not required in an offline dictionary attack. Online dictionary attacks enable the attacker to find the required password by trying all passwords during the interaction with the server [6].
2PAKE protocol has various types of protocols. In 1992, the first 2PAKE protocol (called the Encrypted KeyExchange (EKE)) was proposed by Bellovin and Merritt [7]. Since then, many other 2PAKE protocols have been proposed (e.g. [8]-[12]). One of these protocols was Dragonfly which was defined by Dan Harkins who claimed that this protocol had resistance to passive attacks, active attacks and offline dictionary attacks without security proofs [12]. In 2013, Dylan and Feng analyzed this protocol and proved that this protocol had weakness points in its security properties against active attack and offline dictionary attacks. They proposed to patch Dragonfly as a solution to verify its security properties by adding a public key validation [12].
The main problem in the patched dragonfly protocol was that it consumed an increased computation cost during the execution of the protocol when public key was used, which involved a large bit operation. In this paper,we introduced another enhancement for the Dragonfly protocol without using a public key. The proposed solution is based on using two-pre-shared secret passwords instead of one and the number of rounds between parties has been reduced to two instead of four. This step adds more security to the original Dragonfly protocol while the attacker will require more than 1.5 days to perform the off-line attack in case the shared password is extracted from a dictionary with the size 1000. This result has been approved through a simulation project which was developed by the java programming language. The simulation project has been used to find out the required execution time by both parties who are sharing the communication. The execution time is found to be less than
the time required in the use of public key validation. We also approved the efficiency of Enhanced-Dragonfly protocol by using the Scyther tool to analyze its security properties and its structure.
The paper is organized into sections: Section 2 presents the related work; Section 3 presents review of the Dragonfly protocol; the proposed solution is presented in Section 4, while discussion is presented in Section 5.Finally, the conclusion is in Section 6. It is focused towards those who are interested in cryptography and cryptanalysis domain.Related Work
Password Authenticated Key Exchange (PAKE) protocols have been playing an essential role in providing secure communications. As is usual in cryptography, with each new release of a protocol, attempts to attack this protocol have also been released in order to measure resistance against these attacks.
In research [13], analysis of the security weaknesses of SPAKE1 and SPAKE2 protocols has been introduced.It was found that these protocols are vulnerable against password compromises, impersonation and Denialof-Service (DoS) attacks. Additionally, it was proved that the Hitchcock protocol [14], which uses public key encryptions, is insecure against momentary key compromise masquerades, Key Compromise Impersonation(KCI) attacks and off-line dictionaries. To remove these disadvantages, a new efficient protocol has been designed which relies on two-party PAKE protocols based on symmetric key exchange protocol and multiple hashfunction calculations. The public key scheme has been replaced here with the symmetric encryption because the
latter requires fewer bit operations. Many theories have been explained to prove that the proposed scheme is secure against various attacks. It provides the mutual authentication and forward secrecy attributes with many other security attributes. However, there is a little increase in computational costs that was caused by the extra hash calculations. This may be deemed negligible when considering the efficiency of the extra security attributes and lower number of rounds.
Moreover, another research [15] introduced the vulnerabilities of SPEKE and EKE protocols and analyzed them due to theoretical practices. In addition, a new PAKE protocol was proposed and was called Password Authenticated Key Exchange by Juggling (J-PAKE). It depends on shared secret-password between two entities and it has two rounds to create a strong shared key. It is based on well-established primitive in cryptography called Zero-Knowledge Proof (ZKP) that allows a person to prove his knowledge of a discrete logarithm without revealing it. The analysis of this protocol proved that it prevents off-line dictionary attacks, limits an active attacker to guess only one password per protocol execution and provides forward secrecy. It has advantages like:protection of users from leaking passwords and it does not require PKI deployments. This protocol is very efficient
according to the use of well-established primitives.
Recent researches in the field of PAKE protocols are moving towards using Public Key Infrastructure (PKI) in the authentication process. In recent years, PAKE has been used with RSA encryption method to provide the appropriate secrecy between two parties. In [16] a new proposed protocol named as E3PAKE-RSA, which is based on RSA scheme with the three-party model that enables two entities to only need to remember a humanmemorable
password to authenticate each other and agree on a large session key with the assistance of the trusted server. The public/private key parameters are selected by the clients rather than a trusted distribution center, which makes the process of on-line authentication obsolete. It was predicted that the computation cost for this protocol would be respectively high according to the two-party RSA-PAKE. However, during the testing phase, which applied to the generic constructions, the computation cost of E3PAKE-RSA protocol was found to be as much as the two-party RSA-PAKE and the number of total rounds are less than this. Actually, this protocol requires more time to execute due to the use of the RSA encryption method and the long bit operations, while the other PAKE protocols (which do not use PKI) work faster.
Overview on Dragonfly Protocol
Dragonfly is a PAKE protocol that is used to exchange session keys between two parties with mutual authentication inside mesh networks. It was defined by Dan [12]. Finite cyclic groups are required to implement dragonfly such as Finite Field Cryptography (FFC) or Elliptic Curve Cryptography (ECC) [17]. This paper implements this protocol by using FFC. A finite field is “a field F that contains a finite number of elements which is the order of F” [18]. More details about finite field are presented in.
In this section, we will explain the Dragonfly protocol in detail, with the discovered attack on it followed bythe solution which is suggested in [12].The Proposed Solution
This paper proposes a solution to secure the original Dragonfly protocol without the addition of public key in order to keep the execution time as fast as possible. It relies on using two pre-shared passwords instead of one. Here the attacker must search for each N, P in the dictionary. The first password P will be generated in the same way as in the original Dragonfly protocol. This is done by extracting a string from the dictionary and using the
identities of both parties. It has a length of 1024 bits. The generation of the second password N is the same as Pbut with two minor changes; which are based on the extraction of another word from the same dictionary and the use of the identity of the respondent and it has a length of 160 bits instead of 1024.
The enhanced Dragonfly protocol will work according to the following steps:
Two passwords will be generated, which are P and N, and will be shared between both parties.
Both parties produce scalar and element operations based on choosing one scalar that belongs to Q randomly(r). Then each party will compute his/her scalar (A,B) = r(A,B) + N and element operations E = P – N.
Both parties will compute the hash value of E which is E' = H (E).
The first party will compute the hash value A for the parameters E' and sA. Then A will be sent to the second party with the scalar value of the first party. The second party will verify the hash value A to ensure the authentication process. Here if the hash value is verified then the second party will compute the hash value B and send it to the first party with his/her scalar value SB, otherwise it will be declined. The first party in turn will verify the hash value B. If it is valid then the authentication succeeds.
After that each party will calculate the shared secret which is ss = (PsB E)rA
Then they create a shared secret key which is K = H(ss|E|(sA + sB) mod q).
The benefits of this solution are: firstly, the attacker will never be able to guess the hash value which includes the hash of the element value that uses the exponent of two-secret values. Secondly, the authentication processoccurs in two rounds rather than four rounds as in the original protocol. This elimination makes the execution process go faster. The steps of enhanced Dragonfly protocol have been displayed in Figure 2.
4.1. Methodology over Protocol Testing
A simulation project has been developed to test the time needed to execute the protocol compared to the patched dragonfly protocol. It was written in Java and maintained in Net Beans. This project has been handled by using 64 bits Windows 8.1 pro-operating system and a processor with the speed 2.38 GHz. This project includes three various classes:
Dragonfly: is the main class that has objects from the other two classes and it also has some local variables
such as:
? ID_A, ID_B are identities of initiator and respondent. The identity is the Mac address. For example ID_A =
001CB3098515, ID_B = 001AB3008600.
3) EnhancedDragonfly: is the class that implements the proposed solution. It works as the initiator agent,which is Alice. The respondent agent which is Bob will follow the same steps that are provided by this class.First, a random value rA will be selected from {1,…,q} while q is a Subgroup Order as shown in Table 2. The
passed P and N will be used with rA to calculate Scalar sA, Element E and hash value A. Then these values will be used to calculate the shared secret key. We use MD5 for hash function.
This class includes seven methods:
Enhanced Dragonfly is the constructor that takes p_modularandq as parameters.
scalar_operation: it is calculating scalar operation that is sA = rA + N
element_operation: it is calculating element operation that is E = P N
sending_operation: it is used to calculate and send the hash value A
verifying_operation: It returns true or false according to the verification of the hash value of the other party.
sharedsecret_computation: used to calculate the shared secret key ss, which will be used later in the next equation.
sharedkey_computation: returns the secret key in the form of hash value.
The class diagram of this project is displayed in Figure 3, while Figure 4 presents the input and output of Enhanced Dragonfly protocol simulation. The values of important parameters of Enhanced Dragonfly protocol simulation are listed in Table 2.
By applying this simulation, the execution time for one participant was found to be 19 minutes only. This experiment was applied 15 times in order to measure the total execution time of the enhanced Dragonfly protocol and the average of the total time is almost 38 minutes. This result works as a proof for the efficiency of the proposed solution, and the use of two-shared passwords will not affect the time of exchanging the secret keys.
4.2. Testing and Analysis of the Enhanced Dragonfly Protocol
Any protocol should be analyzed in order to see if there are any possible attacks that can occur and find how secure it is. The automatic analysis is the most recent approach which is used in analysis of security protocols and it is more efficient than the manual one. The required time to write the protocol description depends on the
learning of its language. All possible attacks will be tested by the used tool. The automatic analysis will be used in this research. Various tools are used to analyze the security protocols and to check the possibility of any attack can happen when protocol is put to use. An example for this is the Scyther tool which supports the evaluation of protocols with respect to these corruption models which have led to the automatic detection of many attacks that previously could only be found by manual analysis [22].
4.2.1. Description of Scyther Tool and SPDL
Scyther [23] is one of the most efficient analyzing tools compared with other tools [24]. It was found that this tool can discover attacks more efficiently than others and it can also verify protocols with an unlimited numberof sessions. Its run time is also less than others. There are many protocols that have been analyzed by this tool such as IKEv1, IKEv2 protocol suits, ISO/IEC 9798 family of authentication protocols and MQV family of protocols.
The Scyther tool takes the protocol description as input, and outputs a summary report stating whether the claim was true or false, whether any attack was found or not, and optionally, visual graph descriptions in the dot language from the GraphVizlibrary or representations of trace patterns in XML which describe the trace pattern[25]. Additionally, there are a set of Python bindings for the Scyther command-line tool, which provide a convenient means to script Scyther experiments. Figure 5 displays how this tool works.
Security Protocol Description Language (SPDL) is a language that is used in Scyther for writing a protocol[26]. This language is just expressive enough to capture the most relevant security protocols in an abstract way.It allows us to develop high-level reasoning methods and tools, which can be applied to a large class of protocols.SPDL is used to create a definition for existing protocols that use symmetric or asymmetric encryption. It includes three scopes; global scope (the largest scope), protocol scope (smaller than global) and role scope (thesmallest one). Furthermore, it includes the initial knowledge required to execute a role (each agent’s role includessequence of events, such as sending or receiving a message), the declaration of functions, global constants and variables.
4.2.2. SPDL of Enhanced Dragonfly Protocol and Analysis Result
In this sub-section, the SPDL representation of Enhanced Dragonfly protocol will be explained in detail. After that, the findings from this analysis will be discussed. The SPDL code of the enhanced dragonfly is displayed in Figure 6. First of all, a global hash function H1 & H2 has been defined (outside the protocol definition) to make it available to be accessed by all rolls in the protocol. Also, the functions of multiplication mult, addition add,
exponential exp and the inverse inv were defined globally. Function is a special type which defines a function term that can take a list of variables. By default, it behaves like a hash function: given the term H1(x) where H1 is of type Function, it is impossible to derive x. These functions are defined in an abstract way in SPDL, which doesn’t support any real equations.
Next, the protocol description starts with the keyword protocol which takes the role names as parameters.There are three rolls, namely; the key generator center (role KGC), the initiator (role A) and the respondent (role
B):
? Key generator center role KGC [27]: Used here to pass the shared secret password P and N to role A and B. The way of generation, which is used to generate these shared passwords, doesn’t take a place here in the tool because the tool depends on the structure of the protocol only. The shared secret passwords P&N have been identified as constants and their scope is within the protocol because they should be used inside all
roles.
? Initiator role A:
? This role represents the start of the communication to compute the shared secret key. The selection of random
value rA, which is the first step in the protocol structure (see Figure 2) by Alice (initiator), has been
clarified by using the fresh declaration which is used by SPDL to get random values. Nonce is a standard
data type that is often used in Scyther tool.
? The calculation of SA (Scalar value), E (element value), and A1 (hash value) occurs by using the predefined
functions, and then SA and A1 will be sent to role B.
? Note: labels in recv and send need to disambiguate similar occurrences of events in a protocol specification.
In addition, they are used to link each send event with its recv one [28].
? In the received event of role A, the hash value of B and the Scalar value SB will be saved in a Ticket variable,which can be substituted by any term.Role A will verify if these values are from Role B or not by using the match function. The definition of match [29] ensures the new variable assignment equivalent to the old one and it returns true or false. If the returned value is true then the next steps computed, otherwise Role A will conclude that this value is not from the honest agent, and it closes the session.
? The calculation of the secret key needs to be kept in secrecy, so that a claim with the type secret is used. The main idea behind claim events is locality [28] [29]: that a term is not in the adversary knowledge, or any certain role in run. Secrecy means that if an agent communicates with non-compromised agents, the term should be secret in every trace of the protocol. Secrecy expresses that certain information is not revealed to an adversary, even though this data is communicated over an un-trusted network. Here, claim event has been
used to keep session’s key secret and is known to role A only. When the tool runs, it tries to find the corresponding attack to each claim.
? Respondent Role B:
? Generates the random value rB by fresh declaration.
? Calculates the scalar SB, Element E and hash value B1 and sends it to Role A.
? Verifies the received hash value from Role A and compares it by using match function.
If the output of matching is true, then B will calculate the secret session key and claim it with secret type.The SPDL of the protocol is inserted into the Scyther tool to see if any attack could occur or if there is any structural weak point in this proposed protocol. The result of this analysis brings out that there is NO attack found. All roles are verified, which means that no impersonation can occur during the connection and the characteristics of the protocol structure are verified. This means that the way of exchanging the data is totally secure.This result is printed in Figure 7 and Figure 8.
5、Discussion
5.1. Off-Line Attack Simulation
Attack class has been applied to previous simulation projects. This class works by measuring the time taken to check all possible passwords, as dictionary size varies from 100, 1000 to 100,000 words. Each experiment was performed 5 times to find the search time by attack class and the average value was taken. As a result, the average time of this search within the enhanced protocol increased linearly as with increase in the dictionary size. The average time of off-line search when the dictionary length is 10,000 is more than 1.5 days, and with the
original Dragonfly protocol [12] the off-line search algorithm took an average of 25 seconds to find the correct password with the same dictionary length. This is because the enhanced protocol has an exponential relationship between the two-secret passwords in thecomputation of the element variable. Therefore, the attacker will be forced to search for two words instead of one. As a comparison between the time that is required for searching one password and the time required for searching two passwords, this experiment found that the time increased
exponentially. The search of such an attack on the patched Dragonfly protocol requires few days to be successful. However, here the execution time will have an impact on the efficiency of Key exchange technique. Table 3 shows a linear relationship between dictionary size and the time taken to try all passwords.
5.2. Comparison between Enhanced Dragonfly and Patched Dragonfly Protocols
The enhanced Dragonfly protocol is very similar to the patched Dragonfly protocol except for two minor changes. Firstly, the patched protocol uses only one shared password and a public key, while the enhanced protocol uses two-shared passwords. Second, the rounds between the initiator and the respondent are only two rounds in the enhanced protocol while it is four rounds in the patched protocol. However, the patched dragonfly involves some computational cost because it is uses a public key validation which creates large bit operations due to its large size. This can decrease the protocol efficiency and make it less appealing than its competitors[12]. Otherwise, in the enhanced dragonfly protocol, the execution of the protocol will take less time. In order to measure the execution time of the enhanced Dragonfly protocol we used the simulation project to compute the time required by the key generation center that uses dictionary size 10,000 plus the time which required by the
initiator party when execute the required computation of the protocol. The cost of both patched and enhanced Dragonfly protocol for each participant has been placed into Table 4, and based on these time measurements we have observed that the efficiency of using two-shared passwords is more than using the public key.
The limitation of this research is that these results are based on a normal speed machine with the 64 bits Windows 8.1 pro-operating system and a processor with the speed of 2.38 GHz which is not the case in the real time attack. Furthermore, the attacker is likely to significantly shorten the time of exhaustive search by distributing the calculation over several high performance machines.
