Technische Diskussion zu KNOX - Sammelthread

[atarifreak73]

Ich habe mir zu dem Thema nun diverse Dinge (auch in anderen Foren) durchgelesen, und irgendwie hänge ich immer am gleichen Punkt fest: Dem Löschen der entsprechenden Knox-APKs. /system/app ist ja offensichtlich schreibgeschützt, aber auch ein "su rm /system/app/KNOXAgent.apk" bringt nur ein "Permission denied".
Vielleicht stelle ich mir das ganze ja auch zu leicht vor?

Dank Knox funktioniert EDS nicht mehr, so dass ich keine TC-Container mehr mounten kann. Irgendwie muss sich das noch runterkratzen lassen?

Falls das hier nicht der richtige Thread dazu ist, bitte ich den zuständigen Mod um Nachsicht und Verschiebung an die richtige Stelle.

Sollte ich mit meinen Maßnahmen komplett auf dem Holzweg sein, bitte ich um Erleuchtung.

Übrigens habe ich nicht 4.3 sondern 4.2.2 drauf.

 

[Nightly]

Knox ist nicht nur eine . apk, Knox selbst ist ein elementarer Teil des Gesamt OS... untrennbar miteinander verbunden

 

[Nightly]

Gene S... es ist ja nicht so, dass in jedem relevanten Thread bereits darauf hingewiesen wird (sarcasm)

 

[atarifreak73]

Knox ist nicht nur eine . apk, Knox selbst ist ein elementarer Teil des Gesamt OS... untrennbar miteinander verbunden

Mit andern Worten: ein S4 ohne Knox erfordert ein Custom ROM? Das klingt irgendwie nicht zu Ende gedacht von Samsung.

Gesendet von meinem GT-I9505 mit der Android-Hilfe.de App

 

[flosch1980]

Knox ist nicht nur eine . apk, Knox selbst ist ein elementarer Teil des Gesamt OS... untrennbar miteinander verbunden

Richtig, vor allem war Knox schon vor 4.3 auf dem S4, nur ist es jetzt erst sichtbar aktiv für den User.

Wer sagt mir denn, dass es nicht vorher schon gearbeitet hat, nur dass ich es als User nicht sehen konnte.

 

[Nightly]

Mit andern Worten: ein S4 ohne Knox erfordert ein Custom ROM? Das klingt irgendwie nicht zu Ende gedacht von Samsung.

Wenn Custom = AOSP, dann gebe ich dir gerne zu 97 % recht. Zurecht gemoddete Sammy Roms beinhalten immer noch genügend Knox Restbestände.
..., das Knox Konzept ist final bis ins Detail ausgetüftelt - leider nicht im Sinne der Modding Community und IMHO wohl auch nicht im Sinne des Otto Normal User.

 

[My1]

und wegen der Beschwerden bezüglich des Knox Warranty Void kann ich der Modfraktion zustimmen das das schlecht ist, da ich oft gelesen habe dass n S4 oder n N3 einfach mal abgewiesen wurde wegen Knox Flag bzw. früher Flashcounter obwohl der Fehler damit NICHTS zutun hatte.

und ich bin froh dass es Triangle Away gibt und ich hoffe persönlich, dass sowas ähnliches für den Knox Counter kommt, dass ich unbeschwert Rooten kann denn mein Note 2 hatte (auf 2 Geräte verteilt) Acht oder Neun Garantiefälle die nichts mit Root und co zutun hatten... und hätte es TA net gegeben hätte ich n problem gehabt, sowieso weil letzten dezember der Eigentliche Rootgrund das CWM war wegen Backup...

 

[vetzki]

für cwm musst du aber nicht rooten

 

[My1]

gut nicht direkt Rooten aber den Counter zieht man und ich hab mich eher auf "System verändern" bezogen, und bei allen Geräten die ich Roote kommt CWM drauf und umgekehrt, weil wenn ich CWM drauf hab dann hab ich den Counter und kann dann ja auch gleich Rooten...

 

[atarifreak73]

... leider nicht im Sinne der Modding Community und IMHO wohl auch nicht im Sinne des Otto Normal User.

Dass sich Samsung nicht um die Modding Community schert, kann ich zumindest im Ansatz nachvollziehen, obwohl das auch nicht ok ist. Deine zweite Aussage finde ich aber noch viel schlimmer, denn die Leute stellen die Masse dar und bringen das Geld in die Kasse.

 

[My1]

naja wenn bei nem gecrashten Kies Update der Counter anspringt is das net schon, wie ich auf XDA las...

 

[Prius 3]

und wegen der Beschwerden bezüglich des Knox Warranty Void kann ich der Modfraktion zustimmen das das schlecht ist, da ich oft gelesen habe dass n S4 oder n N3 einfach mal abgewiesen wurde wegen Knox Flag bzw. früher Flashcounter obwohl der Fehler damit NICHTS zutun hatte.

und ich bin froh dass es Triangle Away gibt und ich hoffe persönlich, dass sowas ähnliches für den Knox Counter kommt, dass ich unbeschwert Rooten kann denn mein Note 2 hatte (auf 2 Geräte verteilt) Acht oder Neun Garantiefälle die nichts mit Root und co zutun hatten... und hätte es TA net gegeben hätte ich n problem gehabt, sowieso weil letzten dezember der Eigentliche Rootgrund das CWM war wegen Backup...

Neun Garantiefälle beim Note 2 ?
Also das nenn ich Pech !
Hatte bisher keinen einzigen !

 

[My1]

deswegen hab ich auch 495€ saturngutscheine und nen Grund das N3 zu holn, weil viele ja wegen Geld nicht direkt Upgraden für mich nicht so das Problem...
aber das Geile ist auch immer wieder das Timing meiner Garantie. das Erste mal wo ich mein Geld wieder bekam war am 12.02.2013 ich durfte mir n neues N2 holen und es war aber net vorrätig, also Gutscheine her und ab zum nächsten Saturn die aber noch den Aussteller hatten. Ende vol Lied: Februar bis September hatte ich nen aussteller, ABER 74€ preisfall durch die Zeit und danach noch ne UVP 80€ Karte durch GB-Wochen abgestaubt, yay und naja Ende September anfamg Oktober hab ich zum 2. mal gutscheine gesehen... müssen sich nur noch der Saturn Preis und mein taschengeld treffen, das gute, ich hab in weniger als 2 Wochen Geburtstag...

 

[frank_m]

Es driftet schon wieder mächtig ab hier.

Deshalb jetzt die garantiert letzte Ankündigung diesbezüglich: Sollte es hier noch einen Offtopic Beitrag geben, werden wir den Thread schließen. Neue Beiträge werden dann nur noch möglich sein, indem man eine PN an einen zuständigen Moderator schickt, der ihn zunächst sichtet und dann hier einfügt. Zugelassen werden nur Beiträge, die unmittelbar Aufschluss über technische Eigenschaften oder Verhaltensweisen von Knox geben. Keine NSA Spekulationen, keine Warranty Flag Garantie Fragen, keine Preisvergleiche oder Gutschein Diskussionen! Ich hoffe das war deutlich genug.

 

[Steb]

@frank_m:
Es wäre möglicherweise sinnvoll, deine Aussage im Startpost oder im Titel zu verlinken.

Zurück zum Thema:

Was ist Knox?
"Samsung KNOX™ is the comprehensive enterprise mobile solution for work and play. With the increasing use of smartphones in businesses, Samsung KNOX addresses the mobile security needs of enterprise IT without invading the privacy of its employees."
Frei übersetzt: Samsung Knox ist eine flächendeckende, Mobilgerät-Lösung für Unternehmen. Mit der zunehmenden Nutzung von Smartphones kommt Samsung Knox dem Sicherheitsbedürfnis von Firmen nach, ohne die Privatsphäre ihrer Mitarbeiter zu verletzen.
(Quelle: Samsung)

Wie funktioniert Knox?
(Das ist die große Frage, die wohl alle interessiert. Da ich selbst noch nicht so lange technische Aspekte von Android beleuchte, bin ich nicht in der Lage, alles bis ins kleinste Detail mit 100%iger Richtigkeit darzustellen.
Trotzdem möchte ich es interessenhalber versuchen.)
In den Samsung Knox Whitepapers (ab Seite 3 bzw. laut pdf-Dokument Seite 5) ist darüber einiges nachzulesen.

Ich werde an dieser Stelle erst auf den Secure Boot eingehen, also der Bereich, der das Starten des Smartphones (noch vor dem Bootloader) übernimmt:
dieser verhindert, dass unauthorisierte Software und Betriebssysteme (darunter fallen u.A. Custom-ROMs) beim Bootvorgang gestartet werden.
Das bedeutet, dass nur authorisierte und zertifizierte ("cryptographically signed") Firmware ausgeführt werden kann.
Secure Boot überprüft vom Bootloader, vom Kernel und der System-Software selbst, ob diese durch einen Schlüssel zertifiziert sind. Der Schlüssel widerum ist durch die Hardware verifiziert.
Das entspricht etwa folgender Ereigniskette: Hardware verifiziert geheimen Schlüssel. Schlüssel zertifiziert Software (Bootloader, Kernel, System). Secure Boot überprüft, ob die Software von dem Schlüssel zertifiziert wurde.
(Randbemerkung: verifizieren entspricht einer Überprüfung, zertifizieren meint, die offizielle Herkunft der Software von Samsung nachzuweisen)
Secure Boot benutzt außerdem X.509-Zertifikate (Wikipedia) und öffentliche Schlüssel ("public keys"), diese sind im Bootloader integriert. Ein sicherer Hash-Wert dieser Zertifikate wurde in den Read-Only-Memory gebrannt (bereits während der Produktion!).
Erst wenn sämtliche Software (Bootloader, Kernel, System) überprüft und bestätigt worden ist, wird die Kontrolle an das Beriebssystem übergeben.

Auf die anderen Komponenten werde ich an dieser Stelle aufgrund der Uhrzeit nicht mehr eingehen.

...

Mir ist bewusst, dass ich hier größtenteils Übersetzungsarbeit geleistet habe,
trotzdem finde ich es wichtig, dass man sich an die Details hält (die ich alle versucht habe zu erwähnen!).
Denn gerade bei schnellen und oberflächlichen Übersetzungen gehen unglaublich viele Informationen verloren.

In der Hoffnung, dass einige technisch versiertere Menschen unter euch sind, die diesen Post gelesen haben: ich weiß nicht, inwieweit man Knox als Gesamtprodukt aufschlüsseln kann.
Aber es wäre sowohl interessant als auch zielführend, dem Ganzen etwas näher zu kommen. Ich für meinen Teil mache so etwas gerne.
Wer von euch Fakten (ich wiederhole: Fakten) über die genaueren Funktionen von Knox hat, sich aber nicht (mehr) an dieser Diskussion beteiligen will,
darf mir auch gerne eine PM mit entsprechendem Inhalt schicken.

 

[ollborg]

Da die technischen Details von GD Protected/Knox/SE Android teilweise der militärischen Geheimhaltung unterliegen, ist es schwer technische Informationen zu bekommen. Ich werde versuchen diese trotzdem zu sammeln und ohne Wertung hier zu posten. Um Übersetzungsfehler zu vermeiden, hier der Text in englischer Sprache.

Leider ist es aufgrund der wenigen Informationen nicht immer möglich, zwischen Consumer und Enterprise Knox, zu unterscheiden. Diese ersten Details beziehen sich eindeutig auf GD Protected + Enterprise Knox.

Frank wird hier, durch Reverse Engineering (die Möglichkeit hat er), als einer der wenigen, vieleicht die Möglichkeit haben etwas mehr herauszubekommen.

Quelle:

Top Level Telecommunications: General Dynamics secures commercial smartphones for classified information

http://www.gdc4s.com/gd-protected?taxonomyCat=504


GD Protected for the Samsung Galaxy

For the new Samsung Galaxy S IV smartphone, the GD Protected software comes on top of Samsung's KNOX platform, which was also presented at the Mobile World Congress in February and was developed in cooperation with General Dynamics. KNOX runs a Security Enhanced version of Android, or SE Android, which has been developed by the US National Security Agency (NSA).

The KNOX platform, which is available for government and enterprise users only, protects both data which are stored on the smartphone and data which are sent and received. KNOX creates an isolated and secured container within the memory area, with its own home screen, launcher, applications, and widgets. Applications and data inside the container are separated from applications outside the container. This secured container is created by a TrustZone-based Integrity Measurement Architecture (TIMA).

Stored data are encrypted using an Advanced Encryption Standard (AES) algorithm with a 256-bit key. For secure communications the Samsung KNOX container comes with a FIPS-certified VPN client called "per-app VPN". This supports strong IPSec VPN encryption, including Suite B cryptography, which is suited for the majority of sensitive communications by government agencies.


With the additional GD Protected the original Android operating system of the Samsung Galaxy S IV will be replaced by a hardened Android version with even more security measures. This replacement is done by simply calling General Dynamics with the IMEI number and then the Android operating system will be replaced via an over-the-air reflash.

The hardened operating system includes root certificates from General Dynamics that replace those from Samsung. This means that any subsequent changes need to be digitally signed by General Dynamics, ensuring the integrity of the Android operating system.

Compared to the dual Android operating systems on the LG smartphone, the Samsung solution of installing new firmware offers a slightly higher level of security but at the expense of user freedom. The GD Protected platform for the Galaxy S IV will be available from May 2013.

GD Protected is installed on your commercial device via a simple, over-the-air process:

The carrier specific "Golden Image" is stored on General Dynamics Firmware Over-the-Air (FOTA) servers located in a secure, U.S. based data center
The "Golden Image" is certified for Government Security Requirement Guidelines (SRGs) and provisioned securely using GD specific key

Secure voice and data apps

These secure communications are provided by a number of approved apps from a controlled government or enterprise app store. These include a Secure Voice over IP (SVoIP) app which encrypts voice communications and runs over the data network. Other app offerings, available from the third quarter of this year, will include secure chat and secure video conferencing.

With these apps the (voice) data will be secured using two independent layers of encryption, one at the VoIP layer, and the other at the VPN layer, using IPsec. Finally, these double encrypted data will go through servers of the NSA to be verified, logged, and re-encrypted, before being sent back out to the carrier data network and on to its destination.

For authentication there are a pair of authentication certificates residing on the handsets, as well as users being required to log-in with a password before they can use the SIP server.

Wie wird der Kernel überwacht? TIMA Prinzip. (Auch in Consumer Knox)

Quelle:

https://www.samsungknox.com/overview/technical-details

Samsung KNOX introduces the TrustZone-based Integrity Measurement Architecture. The TrustZone is a tamper-resistant sector of an ARM processor. Protected from software attacks, TIMA ensures that the Linux kernel has not been compromised, by using two techniques:

-Periodically verifying that the kernel has not changed, by calculating code page hashes for the kernel and comparing them against previously calculated values
-Authenticating kernel modules as they are dynamically loaded


ARM TrustZone (In jedem ARM Chip)

Quelle:

http://www.arm.com/products/processors/technologies/trustzone/index.php

TrustZone - ARM

TrustZone technology is tightly integrated tightly into Cortex™-A processors but the secure state is also extended throughout the system via the AMBA® AXI™ bus and specific TrustZone System IP blocks. This system approach means that it is possible to secure peripherals such as secure memory, crypto blocks, keyboard and screen to ensure they can be protected from software attack.

Application Examples

Secured PIN entry for enhanced user authentication in mobile payments & banking
Protection against trojans, phishing and APT (Advanced Persistent Threats)
Enable deployment and consumption of high-value media (DRM)
BYOD (Bring your own device) device persons and application separation
Software license management
Loyalty-based applications
Access control of cloud-based documents
e-Ticketing Mobile TV



SE Android (Auch in Consumer Knox)

Quellen:

http://www.electronicsweekly.com/ey...what-is-security-enhanced-se-android-2013-03/

http://selinuxproject.org/page/SEAndroid

Detailed, specific features of the latest SE Android reference implementation include:

Per-file security labelling support for yaffs2,
Filesystem images (yaffs2 and ext4) labelled at build time,
Labelling support in the recovery console and updater program,
Kernel permission checks controlling Binder IPC,
Labelling of service sockets and socket files created by init,
Labelling of device nodes created by ueventd,
Flexible, configurable labelling of apps and app data directories,
Minimal port of SELinux userspace,
SELinux support for the Android toolbox,
JNI bindings for SELinux APIs,
Userspace permission checks controlling use of the Zygote socket commands,
Userspace permission checks controlling setting of Android properties,
Small TE policy written from scratch for Android,
Confined domains for system services and apps,
Use of MLS categories to isolate apps.


SE Android kernel policy is presently compiled as part of the Android build and added to the ramdisk image so that it can be loaded by init very early in boot, before mounting the system partition. Once the data partition has been mounted, policy can be reloaded from /data/security by placing policy files under /data/security and setting the selinux.reload_policy property to 1 (setprop selinux.reload_policy 1). This will trigger a reload of policy by init, which will also restart ueventd and installd so that they can reload the policy configuration files relevant to their operation.


Policy Updates (Auch in Consumer Knox)

Prior to Android 4.3, we developed a set of extensions to the Android device admin APIs for setting enforcing mode, policy booleans, and providing updated policy files to drop under the /data/security directory. Those APIs are demonstrated by the SEAdmin app. However, the APIs were not accepted into AOSP and are thus only available if you are using our code.

Android 4.3 extended the ConfigUpdate mechanism for handling various kinds of configuration updates to also support SELinux policy updates (via the SELinuxPolicyInstallReceiver). Using this mechanism requires creating a signed policy bundle that can be shipped to the device and then broadcasting an android.intent.action.UPDATE_SEPOLICY Intent on the device to trigger the SELinuxPolicyInstallReceiver to validate the bundle, unpack the policy files from it under /data/security/contexts (with a symbolic link created from /data/security/current), trigger a policy reload to load the new policy files, and then set a new persist.selinux.enforcing Android property based on a SELINUX_STATUS setting. Nothing in AOSP appears to check or use the property, so it is not propagated down to SELinux presently, but it could conceivably be used by some other component to set the SELinux enforcing mode at boot.

We have added a buildsebundle tool to our external/sepolicy project to support building the policy bundle file and metadata file required by the ConfigUpdate mechanism and packaging them into a zip file that can be pushed to the device. We have also extended SEAdmin to support taking one of these zip files, unzip it, and generate the Intent to trigger the policy update. The use of a zip file to package the bundle and the metadata file isn't necessary but is merely a convenience for delivering the files to the device. SEAdmin was also extended to extract the certificate from otacerts.zip on the device and insert it into the Settings.Secure database on boot, which is required for the ConfigUpdate code to verify the bundle signature. Normally this would be handled in some other way as part of the original provisioning of the device.

This new mechanism does not provide the full functionality of SEAdmin; in particular, it does not yet provide a way to set enforcing mode (in a way propagated down to SELinux), to set policy booleans, or to manage the middleware MAC (MMAC) mechanisms. Thus, the device admin APIs and corresponding SEAdmin functionality are still provided on our seandroid and seandroid-4.3 branches. We may be able to eventually eliminate the need for those APIs through extensions to the SELinuxPolicyInstallReceiver code to support the full range of functionality of SEAdmin.

Secure Boot (Auch in Consumer Knox)

Quelle:

https://www.samsungknox.com/overview/technical-details

Secure Boot is a security mechanism that prevents unauthorized boot loaders and kernels from loading during the startup process. Firmware images,that is, operating systems and other system components that are cryptographically signed by known, trusted authorities are considered as authorized firmware. Secure Boot is one of the main components that forms the first line of defense against malicious attacks on KNOX-activated devices.

Samsung KNOX uses systematic security checks to ensure that only valid kernels are used. First, in the hardware, the Primary Boot Loader verifies the integrity of the Secondary Boot Loader 1, by authenticating its signature using a PKI certificate. Similarly, the Secondary Boot Loader 1 verifies the integrity of the Secondary Boot Loader 2, and the Secondary Boot Loader 2 verifies the integrity of the Android Boot Loader. The Android Boot Loader loads only a Samsung-authorized kernel, which has a Samsung certificate as its Root-of-Trust.

Trusted Boot

Trusted Boot is introduced to address these limitations along with Secure Boot on Samsung Knox platforms. During the booting process, each boot loader collects the cryptographic fingerprints (called measurements) of the next boot loader or OS kernel involved in the boot chain, and saves them in the TrustZone secure memory. At system run time, TrustZone applications on the Knox platform will use these measurements to make security critical decisions.

As an example, the TIMA keystore, which is built on the ARM TrustZone framework, stores the cryptographic keys used by the KNOX container. When KNOX authorized firmware runs on a device, it enforces SE for Android, and the KNOX container keys will be protected. However, when a custom Android OS runs on the device, there is no guarantee of the protection of the keys. To defend against this kind of threat, TIMA keystore saves the cryptographic keys through the TrustZone secure world, and releases the keys only when the measurements of the boot loaders and the kernel matches authorized values. When an unauthorized kernel is put on the device, the TIMA keystore detects the mismatch of the measurement and refuses to release the keys.

Attestation

Samsung provides attestation capability for mobile devices, more specifically, the ability to check the integrity of the boot loaders and the kernel. The foundation of attestation is the device's unique public/private key pair. In the factory, each device is provisioned a unique pair of public/private keys along with a certificate for the public key, which is signed by a Samsung root private key. At attestation time, an attestation server sends a random challenge to the device to be tested. An app in the TrustZone retrieves the measurements of the boot loaders and the kernel, signs these measurements along with the random challenge and sends result back to the attestation server for final verification.

 

[My1]

Compared to the dual Android operating systems on the LG smartphone, the Samsung solution of installing new firmware offers a slightly higher level of security but at the expense of user freedom.

sorry das musste jetzt mal sein weil sondt weiß man ja net worau ich mich beziehe...
von Wegen erhöhte Sicherheit, aber das mit dem "auf Kosten von User Freiheit" können se Laut sagen.
selbst wenn das Handy gerootet wäre und eine Knox gehen würde wäre es laut dem ein oder anderem Artikel trotzdem nicht sicher, da man mit root ganz lässig Screenshots erstellen und dann die Touch Koordinaten und damit das Passwort zieht.

Das Dual Android KLINGT zumindest mMn sicherer, da das 2 komplett getrennte System sind wo natürlich dann net mal ne App vom OS1 ins OS2 kann...

 

[bitstopfen]

Du bekommst auch als root keinen Zugriff auf den Container, zumindest wenn man SE Linux im Detail heranzieht, kann das ausgeschlossen werden.

 

[My1]

dann hat man ja gerade noch einen Grud zu sagen das Knox Flag is schrott...

 

[mrx]

Da ich nicht genügend Beiträge habe, um die Bedanken-Funktion zu nutzen, möchte ich an dieser Stelle ollborg für die sehr umfangreiche Sammlung von Informationen danken.

Sehr interessant finde ich die Informationen, die bei Trusted Boot beschrieben sind. Offenbar werden die Schlüssel über die ARM Trusted Zone mit TIMA geschützt. Das beantwortet einige Fragen partiell, die ich hatte, aber aus meiner Sicht trägt die eFuse immer noch nicht wirklich zu mehr Sicherheit bei, dass der Prozess von nichts und niemanden reversibel ist.

Vielen Dank.