KEVIN182: Physical access = game over, root = taky game over, s tim nic nenadelas. No, a nebo to muzes resit trochu podobne jako nyx (byt ten ma jen token, ne klice), udelat private key app-user-specific, takze pokud si ho uzivatel vytahne, tak ... congratulations, muze sam delat ty samy requesty, ktery za nej dela appka.

Zdravím, chtěl jsem se zeptat, jak uchováváte Private Key potřebný pro API komunikaci. Vemu-li v potaz následující odkaz, který se návrhem API zabývá:
Designing a Secure REST (Web) API without OAuth
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

tak tam zmiňuje:
What about the scenario where you are writing a public-facing API like Twitter, where you might have a mobile app deployed on thousands of phones and you have your public and private keys embedded in the app?

On a rooted device, those users could likely decompile your app and pull your private key out, doesn’t that leave the private key open to being compromised?

Yes, yes it does.

So what’s the solution?

Taking a hint from Twitter, it looks like to some degree you cannot avoid this. Your app needs to have its private key (they call it a secret key) and that means you are open to getting your private key compromised.

What you can do though is to issue private keys on a per-application-basis, instead of on a per-user-account basis. That way if the private key is compromised, that version of the application can be banned from your API until new private keys are generated, put into an updated version of the app and re-released.

What if the new set of keys get compromised again?

Well yes, that is very possible. You would have to combat this in some way on your own, like encrypting the keys with another private key… or praying to god people will stop hacking your software.

Regardless, you would have to come up with some 2nd layer of security to protect that new private key, but at least there is a way to get the apps deployed in the wild working again (new version) instead of the root account being locked and NONE of the apps being able to access the service again.

REDTIME: Teoreticky by mohl byt v telefonu nejaky HW AES-on-chip, ale...

DATEL: Imho na posunovani bytu neni moc co optimalizovat. A co znamena pomale? Dnesni CPU v telefonech zase nejsou orezavatka a da se pouzit castecne i GPU... i kdyz to je problematicke. Ale obecne, co pomuze, tak je paralelni zpracovani.

PISKVOR: no, to jsme se jim taky snažili vysvětlit, že to je prostě náročné na CPU a že nějaké urychlení bude znamenat úplné přepsání systému šifrování a dešifrování těch datových kontejnerů, tak jestli by jim opravdu nestačil zaheslovaný ZIP, ale ne, prostě to je málo bezpečné.

Existuje nějaká možnost, jak rychleji provádět tu změnu bajtů? V PHP jsem si udělal nástroj pro dešifrování, lze z toho vyčíst použitý algoritmus:

// $key je pole bytů
while (!feof($in)) {
    $buffer = fread($in, 8192);
    $len = strlen($buffer);
    $position = ftell($in) - $len;
    for ($i = 0; $i < $len; $i++) {
        $key_idx = ($position + $i) % $key_count;
        $delta = $key[$key_idx];
        $buffer[$i] = chr((ord($buffer[$i]) - $delta));
    }
    fwrite($out, $buffer);
} 

(ono samozřejmě zákazník by momentálně nerad předělával serverovou implementaci, takže tlačí na optimalizaci toho, jak to je teď, ale já se obávám, že to prostě nepůjde a bude se muset zvolit opravdu jiné řešení, akorát že s tímhle nemám vůbec zkušenost, tak v tom trochu tápu)

MRAKY: Díky, podívám se na to, akorát to teda vypadá dost robustně, tak nevím, jestli to dám :)

Ještě dodám, potřebuju, aby z takto šifrovaného kontejneru šlo vytvořit "on the fly" stream pro obsažené video a audio soubory.

Ono ta implementace skrz ZIP archiv není úplně špatná myšlenka, odpadá nutnost implementovat právě nějaký kontejner, akorát teda to dešifrování a šifrování je takhle dost pomalé - nevím, jestli by pomohlo, kdyby to bylo jako binární knihovna v NDK.

Případně, nemáte někdo tip na popis nějakých algoritmů pro šifrování velkého objemu dat, které je třeba číst / zapisovat živě, a aby to bylo alespoň trochu svižnější, ikdyž to bude napsané v Javě a ne jako nativní knihovna?

DATEL: podival bych se na tohle:
cryptonite - EncFS and TrueCrypt on Android (**MOVED TO GITHUB**) - Google Project Hosting
https://code.google.com/p/cryptonite/

a na fuse bych se vykvaknul

Řešil jste někdo ve vlastní aplikaci možnost práce se souborovým šifrovaným kontejnerem? Tj. něco jako ZIP formát, ale navíc šifrovaný (zaheslování v ZIP archivu je pro zákazníka nedostatečné).

Koukal jsem na FUSE, akorát že port pro Android už 3 roky neměl žádný update. Navíc jestli jsem to dobře pochopil, tak je nutná podpora v systému (nebo kernelu, nevím), což prý ne každé zařízení má. Ale je možné, že to je potřeba jen v případě, kdy bych chtěl FUSE využít pro globální filesystem.

Vůbec se mi nedaří najít nějaké informace, které by vůbec popisovaly danout problematiku na Androidu.

Převzal jsem jednu aplikaci, která to řeší použitím ZIP archivu a upravenou knihovnou zip4j, kde je přidána třída dědíci z RandomAccessFile, a kde v read() a write() je proveden posun jednotlivých bytů podle nějakého klíče. Problém je, že to je děsně pomalé a nevím (nedaří se mi zjistit), jestli existuje řešení pro optimalizaci nebo jiné řešení šifrovaného kontejneru.

IVONAZ: pridaj jednu nulu nakoniec a vieme sa bavit o tom, ze zapnem pc..

DATEL: budeš muset zkusit, jestli v buildTypes all nebo applicationVariant budeš mít nějak splits přístupné pro každou jednu možnost a změnit to až tam.

Z jiné soudku - vyznáte se někdo více v Gradlu? Jde mi o konkrétní situaci:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 19
    buildToolsVersion '20.0.0'
    ext {
        splitsEnabled = false
    }
    defaultConfig {
    ...
    }
    buildTypes {
        debug {
            ...
        }
        releaseWithLog {
            ...
            splitsEnabled = true
        }
        release.initWith(releaseWithLog)
        release {
            ...
        }
    }
    ...
    splits {
        abi {
            println(splitsEnabled)
            enable splitsEnabled
            reset()
            include 'x86', 'armeabi-v7a', 'armeabi'
            exclude 'x86_64', 'mips64', 'arm64-v8a', 'mips'
            universalApk true
        }
    }
    ...

Na začátku definuju proměnnou "splitsEnabled" (zkoušel jsem i pomocí "def") a nastavím ji na "false". To by tedy mělo platit pro všechny "buildTypes", které nejsou nebo nevychází z "releaseWithLog" - což je v tomto případě jen "debug".

Tj. pak by se "splits" mělo aplikovat pouze pokud builduju pro "release" nebo "releaseWithLog" - proměnná splitsEnabled by měla být "true", v případě buildu "debug" by měla zůstat "false". Problém je, že i v debugu to je nastavené na "true", tj. nefunguje to, jak bych očekával, tj. že to tím "releaseWithLog" projde jen pokud má, ale nastaví to vždy, i při tom debugu (vyzkoušeno, když jsem to tam změnil na nastavení "false", tak ve splits / abi pak bylo skutečně false.

Jde to teda nějak udělat? Díky za pomoc.

REDTIME: díky za tip, až konečně dorazí lízátko na Nexus 7 2013 3G, tak vyzkouším.

No, tak ten GSam Battery Monitor říká, že naše aplikace spotřebovává 0.1% - ale jádro systému 73% - za cca 15 hodin. Tak teď nevím, vzhledem k tomu, že ta aplikace má zaregistrované to upozorňování při změně polohy u systému, mohlo by to být obsaženo v těch 73%? Nevím přesně, jak to ten Android vnitřně vlastně má, co se týče těhle informací o procesech... No, taky je možné, že tu baterku vyšťavil ten monitor :) Zkusím nabít telefon, vypnout v naší aplikaci tu lokalizaci na pozadí a uvidíme. Pak zkusím zase odinstalovat ten monitor... To je na palici, dohledat, jestli je aplikace ok nebo ne, co se týče spotřeby :(

mne to řekne normálně android, pokud nějaká aplikace žere zásadní procento baterky. v nastavení se ukáže u informaci o baterce. moto g 4.4.2

SALUSA_SECUNDUS: o tomhle vím, ale to není to co potřebuju, jestli to dobře chápu, tak to umožňuje sledovat jen obecný stav baterie, tj. jak je nabitá.

MAKROUSEK: zkouším něco podobného, GSam Battery Monitor, wakelocky to taky nějak ukazuje, ale moc se v tom neorientuju, v každém případě u té inkriminované aplikace je minimální spotřeba. Ono teda spotřebu bude spíš dělat ta lokalizační služba systému, která pak jen hodí notifikaci aplikaci, ale ani u té mi nepřišla kdovíjaká nestandardní spotřeba.

DATEL: tohle by mohlo stacit mozna? http://developer.android.com/training/monitoring-device-state/battery-monitoring.html

google: android battery status, prvni odkaz :)

DATEL: Ja pouzival better battery stats, ta pise i jednotlive wakelocky.

MAKROUSEK: jde o starou aplikaci, pro zjišťování polohy se ještě používá LocationClient a jeho metoda requestLocationUpdates(). Request máme omezen na 10 či 20 minut a 250 či 500 metrů a priorita nastavená na PRIORITY_BALANCED_POWER_ACCURACY.

Nicméně spíš by mě zajímalo, jestli lze nějak monitorovat spotřebu, buď nějakou app (ale předpokládám, že bez rootu by to nešlo, takže tato možnost padá) nebo nějakou knihovnou / logováním v aplikaci.

DACAN: V Dagger 2 zatím tápu, tak až přijdu na to, na co se ptáš, tak odpovím :-)

Ahoj, měl byste prosím někdo tip, jak monitorovat vyvíjenou aplikaci v zařízení pro zjištění jak moc a co žere baterku? Klient si stěžoval při testování, že to žere, máme tam službu pro sledování polohy na pozadí, ale mělo by to fungovat jen při větším rozdílu pozice. Navíc na svém telefonu jsem žraní energie nezpozoroval.

Otazka. Pouzivam Dagger 1, ale nemam prilis slozitou app.

Dagger 2. Zkousel nekdo? Otazka se tyka dep. injection obecne, ale uvedu ji na Dagger 2. Vsechno co Dagger 2 nabizi chapu, je to pekne udelany, no injects v modulech, generovanej kod citelnej, takze clovek i vi co to +/- dela, ted jsem v tom lezel dva dny, na Devoxxu uz jsem na to nemel bunky, takze dohanim :D Nicmene: Pouzil by jste nekdo ve vasi soucasne / planovane app dependency na @Component? tzn vyuzil by jste nekdo krom libovule Modulu i vice komponent?

WOJTISHEK: Ahoj s tím oprávněním by mě to také zajímalo - nicméně koukám nad tím

Nová mobilní aplikace mého djského profilu.
Jak se vám líbí?
Btw jsem úplný začátečník, ktetrý si jen tak hraje a budu rád za vaše názory
Díky
Dj Goldstar.apk - Disk Google
https://drive.google.com/file/d/0B5M2xeoo1DEvUWVtYzdqMlJVZnM/view?pli=1