Ich würde auf meinem Fairphone e/os Handy gerne die Gematik E-Rezept App nutzen um meine Arztrezepte prüfen zu können.
Wenn ich über den App Shop die DAK ePA App und DAK App installiere (die wegen meiner Krankenkasse DAK scheinbar? Voraussetzung für die Authentifizierung der E-Rezept App sind) verhält es sich wie folgt:
die DAK ePA App startet nicht sondern schließt sich sofort nach dem Start wieder ohne weiteren Hinweis.
die DAK App öffnet sich zwar meldet jedoch “This app cannot run because the environment is not secure and your data may be at risk”
ich habe beide Apps über die “App Lounge” von eOS installiert.
Vielleicht weiß hier ja ein deutscher Benutzer Rat, da diese Apps und die Gematik E-Rezept App in Deutschland ja relativ hilfreich (unverzichtbar) sind, wenn man z.b. als chronischer Patient regelmässig Arztrezepte einlösen will / muss.
…habe das gleiche Problem mit der DAK App auf dem fp5 und vor ein paar Tagen mit dem Support der DAK telefoniert und den Fall ausführlich beschrieben. Man wollte sich kümmern und ich bin gespannt…
dass man von DAK Seite etwas tut, um gezielt eine eher kleine Randgruppe von /e/OS Benutzern zufrieden zu stellen, kann ich mir ehrlich gesagt kaum vorstellen.
Mir hatte man am Telefon der DAK gesagt, dass Sicherheit für die DAK App sehr wichtig wäre und ich eher darüber nachdenken sollte, ein neues Telefon oder Betriebssystem zu suchen.
Mich persönlich interessiert eigentlich nur die E-Rezept App und ich werde prüfen ob es nicht irgend einen Weg gibt diese App ohne die DAK Apps sauber nutzen zu können um seine Rezepte prüfen zu können.
(die DAK ePA App kommt vom gleichen Publisher wie einige deutsche Krankenkassen, siehe ePA elektronische Patientenakte für einen älteren Thread dazu)
Beide DAK Apps haben den gleichen init*, prüfen Umgebungsvariablen (build.prop) / Build-Fingerprints und sind mindestens unglücklich mit ro.debuggable - Klassiker. Es wird noch mehr geprüft, muss also nicht das ausschlaggebende sein.
Welchem build-channel (stable od. dev) folgst Du mit deinem Gerät @funkrusher ? FP3 stable builds könnten eigentlich (bin da nicht aktuell) normale user-builds sein (statt userdebug). Dort sollte der check durch gehen wenn es nicht noch was anderes ist.
Ich spekuliere ..
… viele Android EntwicklerInnen können gar nicht benennen was die konkrete Gefahr ist (von ro.debuggable oder ro.secure) derer sie sich als Platformbetreiber aussetzen würden bzw vor denen sie NutzerInnen durch das nicht-erlauben schützen.
* relevante Teile der Appstarts
E de.dak.dak_app: Not starting debugger since process cannot load the jdwp agent.
...
I Fingerprint: [20240513-202406061301 b7:b7 33 Fairphone/FP3/FP3:13/6.A.023.1/gms-497e9bef:user/release-keys blocked]
E SELinux : avc: denied { find } for pid=7365 uid=10169 name=н%е*Ñ^е&Ñ/в$и@Ñ scontext=u:r:untrusted_app:s0:c169,c256,c512,c768 tcontext=u:object_r:default_android_service:s0 tclass=service_manager permissive=0
W de.dak.dak_app: type=1400 audit(0.0:111): avc: denied { read } for name="u:object_r:userdebug_or_eng_prop:s0" dev="tmpfs" ino=15555 scontext=u:r:untrusted_app:s0:c169,c256,c512,c768 tcontext=u:object_r:userdebug_or_eng_prop:s0 tclass=file permissive=0 app=de.dak.dak_app
W libc : Access denied finding property "ro.debuggable"
W libc : Access denied finding property "ro.vendor.boot.warranty_bit"
W libc : Access denied finding property "ro.vendor.warranty_bit"
...
D AndroidRuntime: Shutting down VM
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: de.dak.dak_app, PID: 7365
...
E AndroidRuntime: Caused by: java.lang.RuntimeException: DP: 777 08322e3000062b
...
E AndroidRuntime: at de.dak.dak_app.ProtectedDAKApplication.onCreate(Unknown Source:41)
E AndroidRuntime: ... 11 more
I ActivityManager: Showing crash dialog for package de.dak.dak_app u0
# epa app
W a.dakGesundheit: JIT profile information will not be recorded: profile file does not exist.
...
I Fingerprint: [20240222-202403191949 b7:b7 33 Fairphone/FP3/FP3:13/6.A.023.1/gms-497e9bef:user/release-keys blocked]
W a.dakGesundheit: type=1400 audit(0.0:169): avc: denied { read } for name="drivers" dev="proc" ino=4026531853 scontext=u:r:untrusted_app:s0:c168,c256,c512,c768 tcontext=u:object_r:proc_tty_drivers:s0 tclass=file permissive=0 app=com.rise_world.epa.dakGesundheit
W a.dakGesundheit: type=1400 audit(0.0:170): avc: denied { read } for name="modules" dev="proc" ino=4026532117 scontext=u:r:untrusted_app:s0:c168,c256,c512,c768 tcontext=u:object_r:proc_modules:s0 tclass=file permissive=0 app=com.rise_world.epa.dakGesundheit
W libc : Access denied finding property "ro.debuggable"
W a.dakGesundheit: type=1400 audit(0.0:171): avc: denied { read } for name="devices" dev="proc" ino=4026531974 scontext=u:r:untrusted_app:s0:c168,c256,c512,c768 tcontext=u:object_r:proc:s0 tclass=file permissive=0 app=com.rise_world.epa.dakGesundheit
W libc : Access denied finding property "ro.vendor.warranty_bit"
W a.dakGesundheit: type=1400 audit(0.0:172): avc: denied { read } for name="u:object_r:userdebug_or_eng_prop:s0" dev="tmpfs" ino=15555 scontext=u:r:untrusted_app:s0:c168,c256,c512,c768 tcontext=u:object_r:userdebug_or_eng_prop:s0 tclass=file permissive=0 app=com.rise_world.epa.dakGesundheit
...
D AndroidRuntime: Shutting down VM
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.rise_world.epa.dakGesundheit, PID: 11680
...
E AndroidRuntime: Caused by: java.lang.RuntimeException: DP: 777 08322e3000062b
E AndroidRuntime: at com.rise_world.epa.ProtectedFdVApplication.cihsaDntld(Native Method)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
...
E AndroidRuntime: at com.rise_world.epa.ProtectedFdVApplication.onCreate(Unknown Source:41)
Es muss also evtl. noch etwas anderes sein bzw. wenn du es mit Debug getestet hast und der Check wegen Debug nicht durchgeht ist es bisschen schade, weil man ja ohne Debug glaub nicht an die Logs rankommt die du gepostet hast und somit kann ich wohl keine Logs posten, wenn ich auf Stable bin. Dazu kenne ich mich aber auch zu wenig aus.
ja, der init bei dir wird anders aussehen. adb kannst du anmachen trotzdem auch bei einem user-build, wird nur weniger ausführlich sein wegen dem debug-flag. Ich frage mich ob FP3-stable echte user-builds sind.
Werde aus meiner eigenen Logausgabe nicht ganz schlau, das “Access denied” könnte den App init genauso stören wie der Wert der in dem properties-flag steckt bei erfolgreichem auslesen. Kenne den Patch nicht der das Verhindern des Auslesens von Properties möglich macht… oder sind das einfach zu weitreichende selinux regeln die das verhindern?
Seltsam, denn die ePA-Scheufelen muss bei mir (FP4, 2.3-t) letztes Jahr unter 1.xx noch gelaufen sein. Ich hatte eRezept und ePA auf zwei FP4 unter e/os eingerichtet und es funktionierte - jetzt leider nicht mehr. Interessehalber mal Gematik angeschrieben, wurde aber wegen der ePA sofort an meine Krankenkasse verwiesen. Das ist auch komisch, weil die eRezept-App normal startet und wohl eRezept und ePA von Gematik stammen (?).
Hier noch die Antwort meiner Krankenkasse:
Laut dem Anbieter ist e/OS ist ein auf LineageOS basierendes Betriebssystem. Das ist Ihnen sicher besser bekannt als mir es das war und wahrscheinlich nichts Neues. Somit handelt es sich aus Sicht des ePA Anbieters um ein Custom ROM.
Rooted Devices sowie Custom ROMs werden aufgrund von Sicherheitsgründen bzw. Vorgaben nicht von der ePA App unterstützt.
Dies ist durch eigene Sicherheitsvorgaben und die der gematik so geregelt .
Eine Unterstützung für derartige Endgeräte ist insofern nicht möglich.
Leider wird eRezept und ePA ab 2025 noch wichtiger und es wäre schon gut, diese Apps wieder zum laufen zu bekommen. Bis dahin dürfen meine Ärzte zähneknirschend jedes Rezept für mich ausdrucken - was bestimmt auch nervt.
Vielleicht habt ihr es schon überlegt, vielleicht nicht. Vielleicht ist es auch nicht die Lösung, sondern mal ein Versuch wert. Habe ihr es mal probiert auf ein rooted /e/OS und dann mit Magisk Modules und LSPosed-Mods zu cloaken? Bei mir funktioniert das zum Beispiel beim Vodafone App, alle Banking-Apps, jedoch zum Beispiel Payback verreckt es. Die unterfangen immer noch den Root. Versuch wäre es wert.
UPDATE: eben probiert. Vergesse es. Startet nicht mal. Na ja. Wäre für mich ein Grund die Krankenkasse zu wechseln aber nicht bevor ich die schriftlich mitteile das ich gerooted bin WEIL mir Sicherheit ans Herz geht, WEIL ich Privatsphäre wichtig finde und gerade WEIL ich weiß was ich da mache. Die Zeit das Handys mit gefakte roms aus China kamen sind längst Geschichte. Tschüss Krankenkasse, für euch 10 Andere!
Banking ist für mich so ein heikles Thema, dass ich eine solche App nicht auf meinem “daily driver” mit mir herumtragen möchte (ich nutze Banking ausschließlich zu Hause mittels GiroCard und ChipTan per QR-Code).
Eine ePA hat für mich einen ebenso hohen Stellenwert…
Es stellt sich mir die Frage, ob dies Anwendungen sind, die ich ständig benötige und deshalb IMMER dabei haben muss, zumal ich schon von vielen gescheiterten Versuchen gelesen habe, die Root-Erkennung oder auch Unlocked-Bootloader-Erkennung diverser Apps zu umgehen.
Wenn man wirklich auf diese Funktionalitäten angewiesen ist (ePA), dann würde ich dem Trend zum “anonymisierten” Zweitsmartphone folgen: Das Ding wäre mit so wenigen Echtdaten (auch Kontaktdaten etc.) wie möglich eingerichtet und bliebe ausgeschaltet zu Hause, wenn ich es nicht unbedingt, z. B. während des Arztbesuches, benötige…
Mein Beispiel aus der Praxis:
Die App, die ich für meinen Blutzuckersensor benötige und die meine Daten auf irgendwelche Server hochladen möchte, würde unter /e/OS gar nicht funktionieren, hier nutze ich erfolgreich eine App namens JugGluco eines niederländischen Freigeistes . Der Start des Sensors erfolgt mit dem Zweitphone und dieser Original-App, falls dabei was schief gehen sollte und ich der Hotline eine Fehlernummer angeben muss. Danach ist das Zweitphone wieder aus!
Wahrscheinlich einer von vielen Anwendungsfällen, für die man irgendwie eine Lösung brauchen könnte. Ich stelle mir z. B. auch die Frage, wieso ich die eingereichten Abrechnungsbelege für die [Platzhalter für welche private KV auch immer] ständig bei mir haben müsste ?!
Vielleicht hat mein Kommentar dem einen oder anderen genützt…
Das sind gute Ansätze und ich trage mein Smartpone eher selten mit mir rum. Probleme gibt es für mich nur bei wichtigen Anwendungen (aktuelle Bank, Broker, eRezept, ePA…), welche nur noch über Android einsehbar / bearbeitbar sind. Speziell zur ePA möchte ich eigentlich schon wissen, was Ärzte da bei mir an Daten hinterlegen und ein Rezeptabruf, für Bestellungen über das Netz, sollte auch funktionieren. Schön wären auch Desktopalternativen…
An einen Krankenkassenwechsel hatte ich auch schon gedacht, bin aber mit meiner eigentlich ganz zufrieden und e/OS finde ich auch gut.
wäre natürlich gut, dann vorab hinreichend sicher zu wissen, dass die App der neuen KK mit eOS funktioniert.
Ob diese App das dann auch dauerhaft tun wird, das wird wohl keine KK garantieren können (selbst wenn sie gern wollen würde)…
Die Apps kann man ja im Vorfeld testen. Entweder starten die, oder nicht. Persönlich würde ich die Frage an der/die Krankenkasse/n nach Wahl vorher schriftlich per Email stellen und so lange am Ball bleiben bis ich mit einen Entwickler schreibe. Ich kann sehr hartnäckig sein
Oh, das ist in der Tat ein seltenes Nutzungsprofil für ein Mobiltelefon
Das kann ich sehr gut nachvollziehen: Die DKV-App erlaubt es mir nicht, die eingereichten Belege für eine eigene Archivierung zu exportieren. Grundsätzlich ärgert es mich bei Android, dass ich an Daten, die explizit mir gehören, nicht ohne weiteres rankomme: Dazu bräuchte ich wohl Root-Rechte und weitere Fähigkeiten, weil diese Daten vermutlich verschlüsselt sind. Ist das Phone aber gerootet, verweigern diverse Apps den Dienst … grmpf!
Das wäre vermutlich nicht sonderlich vorteilhaft, weil eine neue Versicherung die Kosten für die Leistungen höher setzt oder diverse Leistungen ausschließt, die bei der alten Versicherung vielleicht noch abgedeckt wären.
Netter Versuch, aber wahrscheinlich auch vergebens: Alle Anfragen, die ich bisher gestartet habe, wurden mit Antworten abgewiesen, ich solle doch ein normales Smartphone mit normaler Software benutzen, ansonsten könnten die Firmen keinen Support leisten…
Ich habe bisher noch keine bessere Alternative gefunden, als diese “ominösen” Apps auf dem Zweitphone zu benutzen und auf meinem “daily” nur die Apps zu betreiben, denen ich vertraue, die mich nicht tracken, die mich nicht orten, die mich nicht nerven, die ich auch nicht unbedingt immer dabei haben muss…
Danke für die Anregungen: Ich halte das auch für eine Lösung meiner Probleme: Ein zweites Smartphone anschaffen, voll vergoogelt! Dieses nur im Bedarfsfall einschalten und ansonsten in eine funksichere Hülle!
Damit hätte ich die Kalamitäten mit den Krankenkassen-Apps (Barmer geht nämlich auch nicht), der Roku-App, den einschlägigen Bitcoin- & Banking-Anwendungen gelöst.
Ich werde mir zu dem Zweck ein winziges Unihertz Jelly Star bestellen…
Diese Apps machen einen Zirkus rund um Custom ROMs, testen aber nicht den Stand der Sicherheitsupdates auf dem Gerät?
Nur so eine Frage, ich benutze solche Apps (noch?) nicht.
Die gute Nachricht:
Vielleicht ist es ja schon einigen bekannt, denn man kann die ePA auch in Linux / Windows installieren: https://epaclient.de/ “Bisher konnten Sie ausschließlich über die Patientenakte auf Ihrem Smartphone (mobile App) die Übersicht zu Ihren Gesundheitsdaten behalten. Dies gelingt Ihnen nun auch einfach und bequem über Ihren Computer oder Laptop.”
Die schlechte Nachricht:
Vor der Installation in Linux / Windows muss per Android-App ein ePA-Account eröffet worden sein, damit dann die Anmeldedaten in Li / Wi benutzt werden können. Und es wird ein Kartenleser benötigt (oder jemand bekommt das mit der AusweisApp hin…).
. Der Start des Sensors erfolgt mit dem Zweitphone und dieser Original-App, falls dabei was schief gehen sollte und ich der Hotline eine Fehlernummer angeben muss. Danach ist das Zweitphone wieder aus!
