Full text
RicardoRuizTueros 1
RicardoRuizTueros 2
RicardoRuizTueros ESCUELATÉCNICASUPERIORDEINGENIERÍA INFORMÁTICA INGENIERÍADESOFTWARE ESTABLECIMIENTODECLAVESYAUTENTICACIÓN MEDIANTELAUTILIZACIÓNDECÓDIGOS SONOROSENENTORNOSMÓVILES KEYAGREEMENTANDDEVICESAUTHENTICATION OVERSOUNDCODES Realizadopor RICARDORUIZTUEROS Tutorizadopor ISAACAGUDORUIZ Departamento LENGUAJESYCIENCIASDELACOMPUTACIÓN UNIVERSIDADDEMÁLAGA MÁLAGA,JUNIODE2016 Fechadefensa: ElSecretariodelTribunal 3
RicardoRuizTueros 4
RicardoRuizTueros Resumen Esteproyectotienecomoobjetivoinvestigarlaposibilidadderealizarun intercambiodeclavesyautenticaradosdispositivosutilizandocomomedioel canalsonoro.Investigaremosanivelteóricolaposibilidaddeincluirinformación enunsonidoorientadoalintercambiodeclaves,teniendoencuentafactores comolanecesidaddesincronizarlossonidos,laescuchadelosdispositivos,la longituddelaclavequepodemosalcanzar,losataquesalosqueserían vulnerableelprotocolo,lanecesidaddehacerpersistenteciertainformacióna nivellocal... Trasplantearanivelteóricounaposiblesolucióninvestigaremosdiversas tecnologíasactualesquepuedansoportarla,analizándolasycomparándolas entreellastrataremos,enúltimainstancia,deelaborarunprototipoquesea capazdeautenticaravariosdispositivos(almenosados)yrealizarun intercambiodeclavesentreellos,creandoasíuncanalseguroatravésdelcual puedancomunicarsesinnecesidaddequeunaterceraparteconfiablepueda manejarinformacióncriptográficasensible. Palabrasclave:Investigación,Sonido,Intercambiodeclaves,Autenticación, Seguridad,Terceraparteconfiable,Prototipo. Thisprojecthasasachievementtoinvestigatethepossibilityofmakingakey agreementandauthenticatetwodevicesusingthesoundmedia.Wewill researchatatheoreticallevelthepossibilityofincludinginformationinasound wave,beingawareofdifferentfactsastheneedofsynchronizethesoundsand listensstatesofthedevices,thekeylengthwecanreach,theattackswhich couldvulnerateourprotocol,thenecessityofpersistsomedatalocally… Afterstatingatheoreticalsolutionwewillinvestigatedifferentcurrent technologiesthatcouldhelpusachieveit,wewillanalyzeandcomparethe solutionstryingtoelaborateaprototypewhichwouldbeabletoauthenticate severaldevices(atleasttwoofthem)andmakeakeyagreementbetweenthem, makingasafechannelovertheycancommunicatewithoutatrustedthirdparty thatcanmanipulatethecryptographiccriticaldata. Keywords:Research,Sound,KeyAgreement,Authentication,Security, TrustedThirdParty,Prototype.. 5
RicardoRuizTueros 6
RicardoRuizTueros Índice 1.Ámbitodelproyecto 910 2.Estudiodesolucionesytecnologíaactual 1114 3.Solucionespropuestas 1519 4.Tecnologíasutilizadas 2036 5.Prototipo:Chatchat 3746 6.Conclusionesymejorassobreelproyecto 47 7.Referenciasbibliográficas 4849 7
RicardoRuizTueros 8
RicardoRuizTueros Establecimientodeclavesyautenticaciónmediantela utilizacióndecódigossonorosenentornosmóviles 1. Ámbitodelproyecto Esteproyectopretendeabordarlaproblemáticadelestablecimientodeclaves yautenticaciónentredosdispositivosdeformaseguraparapoderestablecerun canaldecomunicaciónentreellos. Enlaactualidadseutilizanunaseriedeprotocolossegurospararealizareste intercambiodeclaves,comopuedeserelconocidoDiffieHellman ,sinembargo, nuestrapropuestaeslautilizacióndeuncanal“fueradebanda” ,quenospermita realizarlaautenticacióndelosdispositivossinnecesidaddecertificadosydeuna “terceraparteconfiable” comopudieraserunaAutoridadCertificadora(CA),sino entrelospropiosdispositivos. Enestesentidohemosdecididoabordarelproblemadeformasimilaracomo se“autentican” dospersonasenelmundoreal.Enprincipio,nohaynecesidaddeun certificadoquedigaquieneres,simplementerealizamosunreconocimientomutuo delotroindividuoconlainformaciónvisible.Estoesprecisamenteloquetratamos dealcanzar,unaautenticación“espontánea” dedispositivospróximosmedianteel canalsonoro. Lasiguientecuestiónlógicaquepodríamosplantearnoses:“¿Cómopodrían autenticarsedosdispositivos?” ,lacomunicaciónentredispositivosdigitalesenla actualidadserealizaprácticamenteensutotalidadatravésdeInternet,peroeso implicaríalatransmisióndedatosaunservidor,aunaredenlaqueparticipan millonesdeusuariosyquepodríaseratacadademultituddeformas,necesitamos uncanaldecomunicaciónexclusivoentrelosdosdispositivos. ¿QuizáBluetooth?,podríaserunasolución,sinembargotambiénexisten numerososataquesaestatecnología,elalcanceBluetoothpuedeserdevarios metrosconunaantenapequeña,pero,porejemplo,conunaantenadireccionalde grantamaño,podemosalcanzardistanciasdekilómetrosquedanmayorrangoal atacante.Ademásenmuchoscasossomosdependientesdelaplataforma(por ejemplo,nosepuedeemparejarundispositivoconAndroidconunoquetengaiOS). 9
RicardoRuizTueros Además,yaunqueloexplicaremosenelapartadosiguiente,podemos adelantarqueChirpsolonospermiteenviar80bytespormensajeentredispositivos sinpasarporsuservidor,locualreduceeltamañodenuestraclaveonosobligaa enviarlaenvariosmensajes,loquepuederesultartediosoparaelusuarioypuede llevaraproblemasdesincronización. Figura4:Segundaiteracióndelprotocolo Lasegundaaproximaciónqueplaneamosfueutilizarelprotocolo DiffieHellmaniniciadoconunacomunicaciónChirp.Deestaformapodríarealizarse laautenticacióndelprotocolomediantecódigossonorosconelhash delaclave compartida,salvandoasílanecesidaddeuna“terceraparteconfiable” ,seríasimilar alaautenticaciónmedianteloscódigosvisiblesdeTelegram 1 enambos dispositivos. 16
RicardoRuizTueros 1:TelegramMTProtoFAQ https://core.telegram.org/techfaq Sinembargo,aunqueesteesquemaesmásseguro,elprincipalproblemade estaesquesenecesitanenviaralmenostresmensajesconcódigossonoros,uno parainiciarlacomunicaciónconelIDydosmásparalaautenticaciónconelHMAC Figura5:Terceraiteracióndelprotocolo Laterceraaproximaciónfuedesarrollarnuestropropioprotocolobasándonos enlaprimeraidea,perotratandodesolucionareltamañodelaclaveylimitando algunosataquesquepodríanrealizarse,paraellohacemosusodelafunción PBKDF2 (PasswordBasedKeyDerivationFunction2[6]) quenospermitiráapartir delaclavecortaintercambiadaconChirpgenerarunaclavedemayorextensión dadauna“salt”. Paralageneracióndeesta“salt” quedebeserlamismaenlosdos dispositivosutilizamosdosparámetros: Horaactual:Enhorasyminutos,deestaformasabemosquela sincronizaciónseestállevandoacaboenuninstantedetiempo determinadoypodemosevitarquesegrabelaclaveyseutilicecon posterioridad,loqueseconocencomo“ReplayAttacks 1 ”. 1:ReplayAttacksincryptography 17
RicardoRuizTueros http://www2.imm.dtu.dk/~fnie/Papers/GBDN07.pdf RedesWiFi:Ademásdelcódigosonoropodemoscomprobarque ambosdispositivosseencuentranpróximossirecibenlasmismas redesWiFi.ParaelloutilizamoselSSIDalgunasdelasredescon mayorseñal.Deestaformapodemosevitarlosconocidoscomo “WormholeAttacks 1 ” enredesAdhoc,ademásdeañadirentropíaala clavegeneradaconPBKDF2. Unavezcalculadalaclaveporambosdispositivosseprocedeaenviarla informaciónprivadadelusuario(nombreeimagen)cifradasasícomouncódigo HMACqueserviráparaautenticaralreceptoryconfirmarquelaclaveseha calculadocorrectamente. SielcódigoHMACescorrectoseprocedeaañadirlainformacióntransmitida comounnuevocontactoyestablecerunaIDparaelcanaldecomunicaciónconel mismo.Encasocontrariolainformaciónsedescartaynoserespondeconla informaciónpropiaalmensajerecibido. Lainformacióndeloscontactosañadidossealmacenadeformalocalenla aplicaciónynoesaccesibleporelservidor.LasIDssegeneranaleatoriamenteen cadacomunicación,porloquesealmacenanlasIDutilizadasporelemisoryel receptorenlasincronizaciónyseemplean(enunordendeterminado)para establecerlaIDdelcanaldecomunicaciónentreellos. Elobjetivodeestasincronizaciónesqueúnicamenteseenvíenalservidor dostiposdeinformación:IDsaleatoriasdecomunicaciónymensajescifrados. Deestaforma,aunquealguienpudieraatacaryobservarlainformacióndel servidornopodríaconocerelcontenidodelosmensajesenviados,nisiquierapodría identificarusuariosconcretos,yaqueencadacanaldecomunicaciónutilizanID distintos,garantizamosasínosololaconfidencialidaddelosmensajessinotambién laprivacidaddelosusuarios. 1:WormholeAttacksInWirelessSensorNetworks http://www.cs.uml.edu/~glchen/papers/wormholecipbook07.pdf 18
RicardoRuizTueros Sicomparamoslaentropíadelaclaveobtenida,elnúmerodemensajes enviadosatravésdelcanalsonoroylaposibilidaddeataquesderepetición obtenemoslasiguientetabla: Entropía Númerodemensajes mediantecanalsonoro Susceptible AtaquesReplay Claveenclaro 80bytes 1 Si DiffieHellman Másde80bytes 3 No Protocolocon PBKDF2 80bytes+WiFi+ Fecha 1 No Podemosobservarqueencuantoalosparámetrosconsideradosqueel protocolopropuestoesquemejorseajustaofreciendouncompromisoentrela entropíaqueescapazdeutilizarenlaclaveylacantidaddemensajesqueson necesariosenviaratravésdelcanalsonoro. Elprimerprotocolonosofreceunasoluciónsimplesinnecesidaddeenviar variosmensajesatravésdelcanalsonoroperoespocoseguroyaquees susceptibledeataquesderepeticiónysuúnicaentropíasonlos80bytesgenerados conChirp. ElsegundodeellosesunaextensióndelprotocoloDiffieHellman,nosofrece todassusventajasademásdeevitarlosataquesdeltipo“ManInTheMiddle” graciasalaautenticacióndelosusuariosmedianteelcanalsonoro.Seríala soluciónidealentérminosdeseguridadperolanecesidaddesincronizartres mensajessonoroslohacepocousableylento. Eltercerprotocolopropuestoesunamejorasobreelprimeroenelque, graciasalageneracióndeunaclaveconPBKDF2conunasalt adecuada,podemos evitarloataquesderepeticiónyde“agujerodegusano” ademásdeañadirentropía alapropiaclavemedianteelusodelasredesWiFicercanasylafechaactual. Mantienelausabilidaddelaprimeraversiónalnecesitarunúnicomensajeatravés delcanalsonoro. 19
RicardoRuizTueros 4. Tecnologíasutilizadas Enestepuntoseexplicaránlastecnologíasquesehandecididoutilizarenla elaboracióndelprototipo. LaplataformasobrelaquesedesarrollaelprototipoesiOS,estosedebe principalmenteaquelaprimeratecnologíaquetratamosdeutilizarfueAudio Modem yelproyectodepruebaquetraíaesexclusivodeiOS.Ademásnospareció interesantedesarrollarparaestaplataformayaquenosevenadadeellaenla Universidadymitutormeinformódequecontabanconunperfildedesarrollo académicoacordadoentreAppleylaUniversidaddeMálagadelquepodíamos haceruso. SoncuatrolastecnologíasyAPIsutilizadas,aunquenolaúnicasquehe investigado,yaquehemosevaluadootrasalternativascomoAudioModem ,laAPI deTelegram paraelenvíodemensajesoutilizarunservidorwebenlugarde Firebase. ElprincipalproblemadeAudioModem comohemoscomentadoesqueno incluyeunSDKpropiamentedicho,sinosólounproyectodepruebaeniOSconun códigofuentebastantecrípticodelquenopudimosobtenerresultados. PorotrapartelaAPIdeTelegram pareceunabuenasolución,peroaltratar deutilizarsuproyectoeniOShemostenidomuchosproblemasparafirmarelcódigo ydesplegarlaaplicaciónyaquenodisponemosuncertificadoaprobadopor Telegram además,comoveremos,necesitamoscontrolardistintostiposde mensajesquepuedenrecibirlosusuariosennuestroprotocoloyelAPIdeTelegram nonosdacontroldirectosobreesto. Acontinuaciónseexponenlastecnologíasutilizadasexplicandobrevemente lapartedesuAPIquehemosempleadoenelprototipo: 20
RicardoRuizTueros Chirp Chirpesunatecnologíaquesebasaenlacomunicacióndeinformaciónentre dispositivosutilizandoelcanalsonoro. Paraelloempleanunaasociaciónunívocaentreunbyteyunadeterminada frecuencia,deformaqueelcarácter‘a’podríatenerasociadalafrecuenciade 500Hz,elcarácter‘b’lade510Hz… DistinguendostiposdemensajesensuSDK: Los“shortcodes” sonmensajesdeunmáximode80bytes,enviadosen formade10caracteresquenopasanporelservidordeChirpyqueseenvíana travésdelcanalsonorodeundispositivoaotrosiguiendolacodificaciónen frecuenciasanteriormenteexplicadas. Losmensajescondiccionario,porotraparte,sonestructurasdedatosmás complejasqueseenvíanconunaclave,estaclavees,precisamente,un“shortcode” delosanteriormentemencionados.Estosmensajescondiccionarioson,enúltima instancia,unaclavede10caracteresqueidentificaunmensajeenformatoJSON conlainformaciónestructurada. Losmensajescondiccionarioadiferenciadelosmensajes“shortcode” si necesitansubirsealservidordeChirp.Ensufuncionamiento,elusuariofinalrecibe medianteelcanalsonoroun“shortcode” queutilizacomo“token” frentealservidor deChirpparaobtenerlaestructuradedatosenformatoJSON. AcontinuacióncomentamosbrevementelasfuncionesqueChirpnosfacilita: Figura6:FunciónsetAppKey LafunciónsetAppKeyeslaprimeraquedebemosllamarparacomenzara utilizarelSDK(representadoporelobjetosdk),enellaintroduciremosnuestraclave 21
RicardoRuizTueros ysecreto(credencialessolicitadosaChirppersonalmente)paraautenticarnoscomo undesarrolladorregistradoensuservidor. Figura7:FuncionesinitWithIdentifierychirp Lafunciónchirp nospermiteenviarunshortcode ounmensajedetipodiccionario medianteelcanalsonoro,paraelloesnecesariodarelmensaje(unstringparaelshortcode oundiccionarioparaelmensajecondiccionarios)alobjetosdkmediantelafunción initWithIdentifier ,posteriormentebastaconllamaralafunciónchirp enlaquesepuede especificarunbloquedecódigo“withCompletion” queseallamadotraslaemisióndel sonido. . Figura8:FuncionessetOfflineOnlyystartListening Laprimeradeestasfunciones,setOffllineOnly, nospermiteespecificaral objetosdk quenorealizaremosningunacomunicaciónconelservidorenelenvíode mensajes,noesestrictamentenecesario,yaquesinoutilizamosningúndiccionario noseenviaráalservidor,peroesconvenientedesactivarestafuncionalidad. 22
RicardoRuizTueros LafunciónstartListening activaelmicrófonodeldispositivoenmodoescucha alaesperaderecibirunshortcode .Cuandoestoocurreseejecutaelbloquede códigoacontinuacióndelafunción,comoparámetrosincluyeelobjetoChirp recibido,quecontendráelshortcodeenviadoy,encasodeexistir,elobjetoJSON yaconvertidoaunaestructuradediccionario. Además,duranteeldesarrollodelproyecto,Chirphapublicadounanueva versióndesuSDK(alaquehemosactualizado),incorporandounSDKnuevoen iOS:“iOSUIComponents” . EstenuevoSDKnoincorporaningunafuncionalidadadicionalalaya explicada,peronospermiteincluirennuestroproyectoalgunosindicadoresdel estadodelatransmisióndelcódigosonoro. Ennuestrocaso,ycomoveremosenlascapturasdelprototipo,hemos decididoincluirunabarrainferiorenlaquesepuedeapreciarlaondasonora captadaporelmicrófonoentiemporeal,parpadeandoconuncolorverdecuandose recibecorrectamenteunshortkey. EstoselementosdeinterfazsedebenintegrarconelSDKyacomentado anteriormente,acontinuaciónexplicaremosbrevementecómohemosincluidoChirp ennuestroproyecto: Figura9:CómoañadirelframeworkdeChirpalproyecto. ParapoderintegrarelSDKdeChirpenelproyectoarrastramoselarchivo ChirpSDK.framework alapartado“LinkedFrameworksandLibraries” 23
RicardoRuizTueros Figura10:ComprobacióndelframeworkdeChirpenelproyecto. Confirmamosqueelframework sehaañadidocorrectamente,debiendo aparecerunacopiaenlajerarquíadelproyectoyreferenciadoenelapartado“Link BinaryWithLibraries” cómo“Required”. 24
RicardoRuizTueros Firebase Firebase[7]esunatecnologíarelativamentenueva,que,duranteel desarrollodelprototipo,hasidocompradaporGoogle. AunqueahorahaintegradomuchosserviciosconGooglepodemosdefinir Firebaseensuiniciocomouna“BasededatosNoSQLonlinebasadaenJSON”. Enlaactualidadincorporagrancantidaddeserviciosadicionalesen colaboraciónconGooglecomoAnalytics,Autenticación,Almacenamientode ficheros,Hosting,MonetizacióndeaplicacionesmedianteGoogleAdmob.. . Figura11:PáginaprincipaldeFirebase ParaincorporarFirebaseennuestroproyectohemoshechousodelos “CocoaPods”[8] . CocoaPods esungestordedependenciasparaSwiftyObjectiveC,está hechoenRuby eincluyemásde18.000libreríascomúnmenteutilizadasenel desarrollodeaplicacionesiOS. ParautilizarCocoaPodsennuestroproyectohemosdescargadolaaplicación CocoaPods desupáginaweb,alincluirseRubydeformanativaenOSXno necesitamosningunainstalaciónniconfiguraciónprevia. Alabrirlaaplicaciónpodemosseleccionarunproyectodelalistade proyectosexistentesenXCode. 25
RicardoRuizTueros CryptoSwift CryptoSwift[9],talycomosunombresugiere,esunalibreríacriptográficaen ellenguajedeprogramaciónSwift(utilizadoconjuntamenteconobjectivecalolargo deldesarrollodelproyectoiOS). SetratadeunproyectodecódigoabiertoenGithubqueincluyelas operacionesbásicasdecriptografíaqueseutilizanactualmente,entreellas:Hash (MD5,SHA1..512),CRC,Cifrados(AES128..256,ChaCha20,Rabbit),HMAC (MD5,SHA1..256,Poly1305),Modosdebloques(ECB,CBC,CTR…), PasswordBasedKeyDerivationFunction (PBKDF1y2)yPadding(PKCS#7). ParaincluirCryptoSwiftennuestroproyectohemoshechousode Cocoapods ,bastaconespecificarestanuevalibreríacomoun“pod” yactualizarlas libreríasexistentesdesdelaaplicación. Paralasaislarlasoperacionescriptográficasdelcontroldelaaplicación hemoscreadounaclasellamada“CustomCrypto” quecontienelosmétodos necesariospararealizartodaslasoperacionescriptográficasconCryptoSwift ofreciendoelresultadoesperadoalcontroldelaaplicación. Acontinuaciónseexplicalaclase“CustomCrypto” Figura20:Funcionesdecifradoydescifradodeinformacióndelusuario LasfuncionesEncryptUserData yDecryptUserData cifranydescifran(en base64parasuposterioralmacenamiento)lainformacióndelusuarioquetoma comoparámetro.LainformacióndeusuarioaalmacenaresunID,unnombreysu imagendeperfil. 32
RicardoRuizTueros Nótesequeparaobtenerelbloquecifradodedatosoparadescifrarlolos distintosatributosdelcontactoseseparanmedianteelcarácterespacio. Figura20:Funcionesdecifradoydescifradodemensajes Paracifrarydescifrarunmensajedetextobastaconrealizarunallamadaala funciónencrypt odecrypt deCryptoSwift conlosparámetrosadecuados,el resultadodevueltoeselmensajecifradoodescifradoadecuadamente. Figura21:FunciónHMAC LafunciónHMACTimed esunafunciónespecíficaparalageneracióndel códigoHMACdelprotocolo,essencillamenteunafunciónHMACsobrelaclave generadaconPBKDF2quetomacomo“salt” lahoraylasredesWiFi. Figura22:FuncióndegeneracióndelaclaveconPBKDF2 Adicionalmentecontamoscondosfuncionesauxiliaresutilizadasporlapropia clase.LaprimeradeellasesKeywithPKCS5 quenosdevuelveunaclavedemayor tamañocalculadaconlafunciónPBKDF2 utilizandocomofunciónhashSHA256. 33
RicardoRuizTueros Figura23:Funcióndegeneracióndesubclave Lasegunda,lafunciónSubKeynosdevuelveunaclavedeltamañoadecuado pararealizarlasoperacionesdecifradoconAES. Figura24:Funcióndegeneracióndecadenaalfanuméricaaleatoria PorúltimolafunciónGetRandomStringnosdevuelveunacadenade caracteresalfanuméricaaleatoriadelalongitudespecificadacomoparámetro. 34
RicardoRuizTueros JSQMessages JSQMessages[10]esunalibreríadegráficosycontrolquenospermitecrear deformasencillaloselementosbásicosyconundiseñoestandarizadodeuna ventanadechateniOS. Entreloselementosseincluyendiferentesburbujasconmensajes:texto, contenedorasdevideosoimagenes,localizacióngeográfica.Todoanivelde interfazdeusuario. Dadoquesetratadeunalibreríacomplejaylaelaboracióndeunchatessólo unaexcusaparaponerdemanifiestolasoluciónteóricapropuestahemoshechoun usoreducidodeestalibreríalimitándonosalacreacióndeventanasdechat, burbujasdemensajeseindicadoresde“escribiendo…”. Acontinuaciónexplicaremoselusoquehemosdadodelalibrería JSQMessagesparalaelaboracióndenuestroprototipo: Figura25:SubclasedeJSQMessagesViewController Enprimerlugarlaclasedeventanadechatquevayaahacerusodela libreríadebeheredardelaclaseJSQMessagesViewController Figura25:SobreescribiendolafuncióncollectionView 35
RicardoRuizTueros AcontinuaciónnecesitamossobreescribirelmétodocollectionView dela clasepadreparaquecuandosedetecteunnuevomensajeleseaasignadauna burbujadechat,encolorazulsielIDdelremitentedelmensajecoincideconel nuestroyencolorblancoparaelcasocontrario(esunmensajedeotrousuario). 36
RicardoRuizTueros 5. Prototipo:ChatChat ComoaplicaciónprototipoparalautilizacióndelcanalsonoroconChirpe implementacióndelprotocolopropuestohemoselaboradounaaplicacióndechat paradispositivosiOS,quehemosdenominadoChatChat. Acontinuaciónexplicaremoselfuncionamientocompletodelaaplicaciónyla sincronizacióndedosdispositivosmediantecapturas: Enestaprimeracapturaseobservalaventanaprincipaldelaaplicación,en laquepodemosverelnombredelamismaytresbotones. 37
RicardoRuizTueros Sipulsamossobreelbotón“General” nosllevaráaunaventanadechat general.Enlaesquinaizquierdasuperiortenemosunbotónde“Back” conelque podemosvolveralavistaprincipal. Laventanadechatgeneralmuestraenburbujaslosmensajesenviadosal “ChatGeneral”deFirebase,autenticadoscomounusuarioanónimopodemosenviar nuevosmensajesalchatquesealmacenaránenFirebaseenclaroyseránvisibles paraelrestodeusuariosdelasala. NótesequesisalimosyvolvemosaentrarenelchatgeneralFirebasenos asignaunnuevoIDaleatorio,porloquenohayformadeidentificarlosmensajes pertenecientesaunmismodispositivo. 38
RicardoRuizTueros Enlaventanadeperfilpodemoseditarlainformacióndeusuario:nuestro nombreynuestraimagen.Estainformaciónsealmacenaenunficherolocalyes persistenteaunquecerremoslaaplicación. 39
RicardoRuizTueros Sitocamossobrelafotopodemosseleccionarunaimagendelagaleríacomo nuestrafotodeperfil. Estaeslainformacióndelotrousuarioconelquerealizaremosla sincronización. 40
RicardoRuizTueros Siabrimoslaventanadecontactosenambosdispositivos: 41
RicardoRuizTueros 7. Referenciasbibliográficas [1]TactileOneTimePad:LeakageResilientAuthenticationforSmartphones https://www.syssec.rub.de/media/emma/veroeffentlichungen/2015/02/02/vibLogin.pdf [2]SoundProof:UsableTwoFactorAuthenticationBasedonAmbientSound http://arxiv.org/pdf/1503.03790.pdf [3]Signal360(AnteriormenteSonicNotify) http://www.gizmag.com/sonicnotifyaudiosignals/21385 [4]AudioModem.Dataoversound. https://applidium.com/en/news/data_transfer_through_sound/ [5]Chirp http://chirp.io [6]PBKDF2(PasswordBasedKeyDerivationFunction2)RFC https://tools.ietf.org/html/rfc2898#section5.2 [7]Firebase https://firebase.google.com/ [8]CocoaPods https://cocoapods.org/ [9]CryptoSwift https://github.com/krzyzanowskim/CryptoSwift [10]JSQMessages https://github.com/jessesquires/JSQMessagesViewController/tree/master 48
RicardoRuizTueros [11]FuncióncercanoutilizadaporGoogleenAndroid https://support.google.com/accounts/answer/6260286?p=google_settings_nea rby&rd=1 [12]TheSwiftProgrammingLanguage(Swift3beta).iBookversion. https://itunes.apple.com/es/book/swiftprogramminglanguage/id1002622538? mt=11 [13]UsingSwiftwithCocoaandObjectiveC(Swift2.2).iBookversion. https://itunes.apple.com/es/book/usingswiftcocoaobjective/id888894773?mt= 11 49