Why Samsung phones are considered more secure than the other stock androids?
I watched one video (i think it was Techlore’s) where it was mentioned that Samsung kernel is 4 times larger than that of stock Android. So i have a few questions:
Doesn’t that make the phone extremely not secure as the attack surface is so large. Even with Knox the kernel being 4 times larger calls for a lot of potential vulnerabilities in that kernel.
Does Samsung deviate from the stock android security model? If they modify android so much for their phones does that mean that android security model has been modified as well?
If my reasonings for the above 2 points are correct then a Motorola phone or a Sony phone should in theory be more secure right? Smaller kernel, less attack surface, no OEM bloat, close to stock android.
I understand what you mean and i know what Knox offers. But even with real time kernel protection don’t you think a larger kernel is more prone to vulnerabilities and thus not secure even with Knox?
more secure? since when? as i remember brand new samsung devices was hacked after only a few seconds on a Hackers Convention last time (s23, s23 Ultra) of course samsung fixed it later but…
This is what the consensus is in the “community” but my logic tells me this cannot be correct. For me the more bloat and more modified android = less secure. So OEMS that are closest to stock android should be more secure in theory. They do not add unnecessary attack surface and maitain android as it is. People here seem to care only about updates.
Samsung in general offers longer support than any other large manufacturer (after Google, not counting Fairphone). So if you plan to use your phone for more than 2 or 3 years (and you should, as hardware is good), Samsung is your best bet, as even the lower-end models, e.g. ~200€ Galaxy A35 has 4 years support.
I do agree those phones are full of bloatware and/or unnecessary apps, but after you disable/remove all of them, it is ok.
This is bullshit, samsung device are supported for long, yes. But to say they got timely update is nonsensical
I have a samsung M15, released on March 2024. As of right now (22 sept 2024), the latest update this OS got is from 27 June 2024. Some third party link for verification.
I actually dont have a very postive impression of Samsung’ security. It was deemed better back in thr day due to KNOX but that is a long time ago all those features are all/mostly ported in to stock Android and Google Play Services.
I think the idea of Samsung phones being more secure is dated. But sure if you can’t get a Pixel or iPhone it might be the most update reliable phone and then and only then it may be a the best option.
Which was pwned rather devastatingly, back in the day.
In the mobile device world, security traditionally relied on kernel mechanisms. But history has shown us that the kernel was far from being unbreakable. For most Android devices, finding a kernel vulnerability allows an attacker to modify sensitive kernel data structures, elevate privileges and execute malicious code.
It is also simply not enough to ensure kernel integrity at boot time (using the Verified Boot mechanism). Kernel integrity must also be verified at run time. This is what a security hypervisor aims to do. RKP, or Real-time Kernel Protection, is the name of Samsung’s hypervisor implementation which is part of Samsung KNOX.
Non-exhaustive list of requirements for future devices, which are standards met or exceeded by current Pixel devices:
Support for using alternate operating systems including full hardware security functionality
Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)
At least 5 years of updates from launch for device support code with phones (Pixels now have 7) and 7 years with tablets
Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they’re released)
Linux 6.1 or 6.6 Generic Kernel Image (GKI) support
Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM to match Pixels but another usable implementation may be acceptable)
Hardware memory tagging (ARM MTE or equivalent)
BTI/PAC, CET or equivalent
PXN, SMEP or equivalent
PAN, SMAP or equivalent
Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode / decode, image processor and other components
Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times
Verified boot with rollback protection for firmware
Verified boot with rollback protection for the OS (Android Verified Boot)
Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
StrongBox keystore provided by secure element
Hardware key attestation support for the StrongBox keystore
Attest key support for hardware key attestation to provide pinning support
Weaver disk encryption key derivation throttling provided by secure element
Insider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
Inline disk encryption acceleration with wrapped key support
64-bit-only device support code
Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
Support for disabling USB data and also USB as a whole at a hardware level in the USB controller
Reset attack mitigation for firmware-based boot modes such as fastboot mode zeroing memory left over from the OS and delaying opening up attack surface such as USB functionality until that’s completed
Samsung devices are by far the closest to meeting these requirements, the only problem is that Samsung permanently breaks security features if you unlock the bootloader and doesn’t support alternative operating systems.
What you list may be necessary, but will never be sufficient.
The weakest link in Smartphones, besides the bugs in Linux and Android’s C/C++ portions, is firmware and the OEM software. The system will only ever be as strong as its weakest link. Though, this may come off as a defeatist position for typical consumers, for high-risk professionals, such paranoia is a reality.
In short, we need a GrapheneOS-like project in the OEM space. I imagine it will be an insanely captial intensive endeavour, and potentially capital destructive endeavour, too. We need an absurdly motivated, relentlessly persistent, insanely competent lead to pull-off such a project (like Daniel Micay has). Andrew “Bunnie” Huang sounds like someone who can make it happen.
While this is a problem, some of it should be mitigated. Some (all?) firmware should be isolated through IOMMU. System processes should only be able to access the hardware’s drivers through sandboxed HALs.
GrapheneOS tried to work with a vendor to make a smartphone with better security.
Sure, let’s do something more expensive then. Samsung A55, their latest highest end mid-range. The time between updates is still often reaching 3-4 weeks
You can’t just say Samsung has good update schedule, and need to specify which model (because even their high end has questionable schedule). My point stands, samsung updates are not timely nor consistent