精华内容
下载资源
问答
  • 系统安全机制
    千次阅读
    2021-05-14 11:08:46

    AG351.SELINUX

    SElinux 是一个强制访问控制系统,它为每个进程与文件都打上一个安全上下文标签,而 selinux 通过这个标

    签对系统访问控制进行管理。

    2.针对车载产品对于启动安全、平台运行安全、通信安全三个主要领域有着

    特 殊 很 高 的 要 求 , 为 此 Quectel 结 合 了 Qualcomm 给 出 的 secureboot 、QSEE/TrustZone安全机制以及Linux系统的DM-verity、SELinux和openSSL等组合方式,实现从启动到客户进程安全稳定运行,防止出现盗窃取、篡改客户信息和文件等重要信息。

    实时更新各层安全漏洞

    通信安全基于iptabel(针对客户特定的应用场景实现各种复杂安全路由策略),Openssl(定时完善安全漏洞、协助客户开发),实现安全可靠的网络通信。

    平台安全基于QSEE/TZ,SELinux等机制,实现linux系统资源文件保护,程序安装和执行,网路安全。QUECTEL 提供动态灵活的分区和文件系统机制,从而增加文件的存储安全以及FLASH 寿命QSEE/TZ TrustZone 提供一个可信程序执行环境(TEE)(包括内存安全、外设访问安全等),保证你的代码运行时不能被别人窥探到。

    固件保护:跟文件系统只读、备份还原机制、可定制化分区;

    启动安全基于QC-Secboot(内核安全启动/镜像签名),DM-Verity(文件系统安全校验,实现启动文件验证标签、文件系统安全),硬件调试接口关闭,本地通信接口关闭等(关闭jtag、fastboot、adb、串口、usb口)。(启动流程校验、优化、规范化)

    A7平台安全机制

    A7安全启动

    1.安全引导系统在启动过程的每个阶段添加加密检查。设备执行的软件镜像必须经过安全校验。这种额外的检测能够防止非法串改的软件在设备上运行。

    安全引导,通过hardware fuses识别被标记的启动镜像;

    签名工具,

    2.每个阶段启动一个镜像,被之前一个镜像检测;

    ROMCODE是最先信任启动的;

    每个阶段授权下一个阶段:ROMCODE->bootloader->ARM TrustZone->每个镜像通过其功能,建立设备安全性;

    3.使能安全启动ROMCODE 和bootloader

    (1) 将默认的key改变成用户使用的key,在目录SOURCE_DIR/sbu/keys/使用命令:$ openssl genrsa –aes256 -out key.pem 2048

    (2) When prompted about the pass-phase for RSA key, put pass-phase inpassphrase.txtinthe same directory.

    (3)Get user public key HASH and HASH ZERO bits count by the command tool:

    $ python3

    SOURCE_DIR/sbu/src/secure_boot_utils/sbu_main/primary_key_hash_creat

    or.py SOURCE_DIR/sbu/keys/rsakey.pem ../keys/passphase.txt L

    SHA256_TRUNC

    (4)Write public key HASH and zero bit count into OTP.

    使能安全启动需要以下相关配置:

    Secure boot configurations

    0xB[7:0]Number of bit 0 in User Public Key HASH

    0x10 – 0x13[31:0]User Public Key HASH

    ROMCODEBootloader in signed formatCsrvisor、kernel

    load and verifiesBootloader loads andverifies TrustEnvironment withSHA256 digest.

    SHA and RSASHA and RSA | RSA

    4.引导加载签名格式

    RSA 密匙证书和镜像签名;

    证书签名格式为:SHA256;

    M3安全启动

    1.对启动镜像进行安全校验。

    安全性

    一、安全特征

    1.平台安全

    启动校验:A7、M3、Kalimba Audio(音频处理器)

    生命周期状态:通过控制对设备的产生和管理决定设备的安全能力

    客户机密安全配置(密匙和证书)

    安全调试

    RMA mode :快速诊断由于缺陷而返回的设备

    2.内容保护

    cortexA7 TrustZone、SRAM、DRAM等

    3.安全

    对硬件单元的访问控制的配置寄存器的防火墙保护

    分区的NOC映射

    4.第三方应用的执行

    A7提供资源(TEE),允许执行第三方应用程序,同时保留

    平台的完整性、安全性、内容保护性、安全性等特点。

    5.软件许可与版本控制

    二、安全资源

    1.Trusted Execution Environment(TEES)

    TrustZone extensions、DRAM 、SPRAM、regitsters、crypto engines、OTP 、ROMcode.etc

    2.微型控制子系统(MCS)

    cortex M3,Network on chip,SHA-256 engine,ROM code.

    3.常供电区域

    TEES MCS

    4.IPC

    内部处理器通信机制带安全机制

    5.安全DMA

    大多数DMA通道可配置成安全模式和非安全模式

    三、生命周期状态(LCS)

    芯片制造、设备制造、安全、安全禁用。

    四、认证启动

    cortex M3、cortex A7

    五、安全子系统

    平台安全由安全子系统硬件支持

    六、MCS 安全

    MCS安全包括SH-256和AES-128加密硬件控制器。

    七、配置TEE

    1.内存防火墙

    SPRAM、DRAM

    防火墙用于设置针对特定发起方的内存缓冲区,并可以提供不同的访问。

    对于不同的发起人和不同权限的读/写访问的缓冲区的权限。

    2.寄存器防火墙

    寄存器防火墙可以被配置为保护块(地址范围)免受特定CPU发起人,其他,非

    在任何情况下,CPU发起人都无法访问寄存器。

    3.KAS、ARM和cortex M3 安全通信传输

    4.NoC安全边带信号

    八、配置IPC安全

    安全配置应该使用NFWW边带管理器根据安全要求划分这些。

    九、DMA控制器

    每个DMA控制器(除DMAC1由NOC目标防火墙(NTFW)保护)

    根据相关联的安全状态,每个DMAC信道可以被配置为安全或非安全的。

    十、安全性

    安全性是通过在ARM CORTEX-A7(CA7)和ARM CORTEX-M3(CM3)之间划分单元来实现的。

    十一、调试

    ARM使用术语“安全调试”,这意味着CaleSee硬件可以生成安全事务。

    调试与安全相关的项。安全调试还涉及安全设备的调试。

    十二、供应

    供应是引入OEM特定机密(例如DRM密钥)和完整性关键数据(例如证书)的行为再进入系统

    十三、区域返回操作/RMA

    车载安全机制

    一、硬件安全

    1.主板安全(主板上调试接口、测试点安全评估)

    2.存储安全(敏感器件标识、存储器件安全评估)

    3.总线安全(can总线安全协议)

    4.无线模块安全

    二、软件安全

    1.代码逻辑安全

    2.日志输出安全

    3.运行数据安全

    4.通信安全(4G、wifi、蓝牙等)

    5.业务逻辑安全

    6.启动安全

    7.权限控制

    8.更新安全

    9.操作系统安全

    10.应用安全(应用系统和应用程序的安全)

    11.可修复安全

    12.固件安全(存储安全、启动安全、升级安全)

    13.系统安全加固和漏洞利用缓解

    (1)开启随机数生成开关(CONFIG_ARCH_RANDOM)、选择对应随机数生成硬件平台(CONFIG_HW_RANDOM)

    (2)开启审计支持(CONFIG_AUDIT)、支持对系统调用审计(CONFIG_AUDITSYSCALL)

    (3)开启SYNcookie以应对拒绝服务攻击(CONFIG_SYN_COOKIES)

    (4)开启栈溢出保护(CONFIG_CC_STACKPROTECTOR)

    (5)开启内核只读数据不可写(CONFIG_DEBUG_RODATA)

    (6)约束root权限对/dev/mem访问权限(CONFIG_STRICT_DEVMEM)

    (7)关闭/proc/kcore内存映射(CONFIG_PROC_KCORE)

    (8)开机系统内核日志访问控制(CONFIG_SECUITY_DMESG_RESTRICT)

    (9)开启内存也可执行权限检查(CONFIG_PAX_NOEXEC)

    (10)开启内存权限检查(CONFIG_PAX_MPROTECT)

    (11)开启地址空间布局随机化(CONFIG_PAX_ASLR)

    (12)开启内核栈布局随机化(CONFIG_PAX_RANDKSTACK)

    开启用户控件栈布局随机化(CONFIG_PAX_RANDUSTACK)

    (13)开机映射空间布局随机化(CONFIG_PAX_RANDMMAP)

    (14)开启/proc目录安全加固(CONFIG_GRKERNSEC_PROC)

    (15)开启/proc目录用户隔离(CONFIG_GRKERNSEC_PROC_USER)

    (16)开启/proc目录用户组隔离(CONFIG_GRKERNSEC_PROC_GROUP)

    (17)阻止非root用户访问设备信息(CONFIG_GRKERNSEC_PROC_ADD)

    (18)阻止查看其它用户LINK信息(CONFIG_GRKERNSEC_LINK)

    (19)阻止用户向其他用户管道进行写入(CONFIG_GRKERNSEC_FIFO)

    (20)CHRROOT安全策略加固(CONFIG_GRKERNSEC_CHROOT)

    (21)开启可执行文件与脚本白名单配置(CONFIG_GRKERNSEC_TPE)

    (22)自主访问控制(访问权限控制USER-GROUP-OTHER、Linux Capability机制、安卓权限机制)

    (23)强制访问控制(SELINUX、APPArmor、基于linux内核系统模块)

    三、移动app

    应用安全(应用系统和应用程序的安全)

    身份认证、会话管理、敏感数据存储传输、组件安全、常见安全漏洞、不安全运行环境。

    四、云平台TSP

    更多相关内容
  • Android系统安全机制

    2021-03-29 16:53:18
    Android 将安全设计贯穿...Android系统架构可以分为4层结构,由上至下分别是应用程序层、应用程序框架层、系统运行库层以及内核层,如图1所示。 Android应用层允许开发者无须修改底层代码就能对设备的功能进行拓展,
    Android 将安全设计贯穿系统架构的各个层面,覆盖系统内核、虚拟机、应用程序框架层以及应用层各个环节,力求在开放的同时,也能保护用户的数据、应用程序和设备安全。

    Android是一种基于Linux的、自由的、开源的操作系统。它主要使用于移动设备,如智能手机和平板电脑,由Google公司和开放手机联盟开发。Android系统架构可以分为4层结构,由上至下分别是应用程序层、应用程序框架层、系统运行库层以及内核层,如图1所示。

    Android系统安全机制Android系统安全机制

    Android应用层允许开发者无须修改底层代码就能对设备的功能进行拓展,Android的应用程序框架层为开发者提供了大量的API来访问Android的设备。

    Android 应用和Android 框架都是用 Java 语言开发的,并运行在 DalvikVM 中运行。DalvikVM的作用主要就是为操作系统底层提供一个高效的抽象层。DalvikVM是一种基于寄存器的虚拟机,能够解释执行Dalvik可执行格式DEX的字节码,Android 应用和Android 框架都是用 Java 语言开发的,并运行在 DalvikVM 中运行。DalvikVM的作用主要就是为操作系统底层提供一个高效的抽象层。DalvikVM是一种基于寄存器的虚拟机,能够解释执行Dalvik可执行格式DEX的字节码,

    Android 将安全设计贯穿系统架构的各个层面,覆盖系统内核、虚拟机、应用程序框架层以及应用层各个环节,力求在开放的同时,也能保护用户的数据、应用程序和设备安全。

    1.Android进程沙箱隔离机制

    进程沙箱隔离机制,使Android应用程序在安装时被赋予独特的用户标识(UID),并永久保持。应用程序及其运行的Dalvik虚拟机运行在独立的Linux进程空间,与其他应用程序完全隔离,如图2所示。

    Android系统安全机制Android系统安全机制

    在特殊情况下,进程间还可以存在相互信任关系。如源自同一开发者或同一开发机构的应用程序,通过Android提供的共享UID(Shared UserId)机制,使具备信任关系的应用程序可以运行在同一进程空间。

    2. 应用程序签名机制

    规定 APK 文件必须被开发者进行数字签名,以便标识应用程序作者和在应用程序之间的信任关系。在安装应用程序APK时,系统安装程序首先检查APK是否被签名,有签名才能安装。当应用程序升级时,需要检查新版应用的数字签名与已安装的应用程序的签名是否相同,否则,会被当作一个新的应用程序。Android 开发者有可能把安装包命名为相同的名字,通过不同的签名可以把它们区分开来,也保证签名不同的安装包不被替换,同时防止恶意软件替换安装的应用。

    3. 权限声明机制

    要想在对象上进行操作,就需要把权限和此对象的操作进行绑定。不同级别要求应用程序行使权限的认证方式也不一样,Normal级申请就可以使用,Dangerous级需要安装时由用户确认,Signature和SignatureOrSystem级则必须是系统用户才可用。

    4. 进程通信机制

    基于共享内存的 Binder 实现,提供轻量级的远程进程调用(RPC)。通过接口描述语言(AIDL)定义接口与交换数据的类型,确保进程间通信的数据不会溢出越界,如图3所示。

    Android系统安全机制Android系统安全机制

    5. 内存管理机制

    基于Linux的低内存管理机制,设计实现了独特的LMK,将进程重要性分级、分组,当内存不足时,自动清理级别进程所占用的内存空间。同时,引入的 Ashmem 内存机制,使Android具备清理不再使用共享内存区域的能力。

    正是因为Android采用多层架构,在保护信息安全的同时,也保证开放平台的灵活性。

    展开全文
  • Android系统安全机制研究.pdf
  • 浅探制定Android系统安全机制.pdf
  • Android系统安全机制的应用.pdf
  • Android系统安全机制研究 (2).pdf
  • Android安全机制

    千次阅读 2018-04-29 08:45:12
       Android是一个基于Linux内核的移动操作系统。Linux是一个支持多用户的系统系统中的...Android在Linux内核提供的基于UID和GID的安全机制的基础上,又实现了一套称为Permission的安全机制,如图1所示:   ...

     

     

            Android是一个基于Linux内核的移动操作系统。Linux是一个支持多用户的系统,系统中的文件的访问权限是通过用户ID(UID)和用户组ID(GID)来控制的。换句话说,就是Linux的安全机制是基于UID和GID来实现的。Android在Linux内核提供的基于UID和GID的安全机制的基础上,又实现了一套称为Permission的安全机制,如图1所示:

     

     

    图1 Linux的UID/GID安全机制与Android的Permission安全机制

            那么,这两个安全机制是如何对应起来的呢?

            我们首先看一下Linux基于UID和GID的安全机制,它包含三个基本角色:用户、进程和文件,如图2所示:

    图2 Linux基于UID/GID的安全机制的三个角色

            Linux中的每一个用户都分配有一个UID,然后所有的用户又按组来进划分,每一个用户组都分配有一个GID。注意,一个用户可以属于多个用户组,也就是说,一个UID可以对应多个GID。在一个用户所对应的用户组中,其中有一个称为主用户组,其它的称为补充用户组。

            Linux中的每一个文件都具有三种权限:Read、Write和Execute。这三种权限又按照用户属性划分为三组:Owner、Group和Other。如图3所示:

    图3 Linux的文件权限划分

            从图3就可以看出文件acct:1. 所有者为root,可读可写可执行;2. 所有者所属的主用户组为root,在这个组中的其它用户可读可执行;3. 其余的用户可读可执行。

            Linux中的每一个进程都关联有一个用户,也就是对应有一个UID,如图4所示:

    图4 Linux的进程

             由于每一个用户都对应有一个主用户组,以及若干个补充用户组,因此,每一个进程除了有一个对应的UID之外,还对应有一个主GID,以及若干个Supplementary GIDs。这些UID和GID就决定了一个进程所能访问的文件或者所能调用的系统API。例如,在图4中,PID为340的进程一般来说,就只能访问所有者为u0_a19的文件。

             一个进程的UID是怎么来的呢?在默认情况下,就等于创建它的进程的UID,也就是它的父进程的UID。Linux的第一个进程是init进程,它是由内核在启动完成后创建的,它的UID是root。然后系统中的所有其它进程都是直接由init进程或者间接由init进程的子进程来创建。所以默认情况下,系统的所有进程的UID都应该是root。但是实际情况并非如此,因为父进程在创建子进程之后,也就是在fork之后,可以调用setuid来改变它的UID。例如,在PC中,init进程启动之后,会先让用户登录。用户登录成功后,就对应有一个shell进程。该shell进程的UID就会被setuid修改为所登录的用户。之后系统中创建的其余进程的UID为所登录的用户。

            进程的UID除了来自于父进程之外,还有另外一种途径。上面我们说到,Linux的文件有三种权限,分别是Read、Wirte和Execute。其实还有另外一个种权限,叫做SUID。例如,我们对Android手机进行root的过程中,会在里面放置一个su文件。这个su文件就具有SUID权限,如图5所示:

    图5 su的SUID和SGID

            一个可执行文件一旦被设置了SUID位,那么当它被一个进程通过exec加载之后,该进程的UID就会变成该可执行文件的所有者的UID。也就是说,当上述的su被执行的时候,它所运行在的进程的UID是root,于是它就具有最高级别的权限,想干什么就干什么。

            与SUI类似,文件还有另外一个称为SGID的权限,不过它描述的是用户组。也就是说,一个可执行文件一旦被设置了GUID位,么当它被一个进程通过exec加载之后,该进程的主UID就会变成该可执行文件的所有者的主UID。

            现在,小伙伴们应该可以理解Android手机的root原理了吧:一个普通的进程通过执行su,从而获得一个具有root权限的进程。有了这个具有root权限的进程之后,就可以想干什么就干什么了。su所做的事情其实很简单,它再fork另外一个子进程来做真正的事情,也就是我们在执行su的时候,后面所跟的那些参数。由于su所运行在的进程的UID是root,因此由它fork出来的子进程的UID也是root。于是,子进程也可以想干什么就干什么了。

            不过呢,用来root手机的su还会配合另外一个称为superuser的app来使用。su在fork子进程来做真正的事情之前,会将superuser启动起来,询问用户是否允许fork一个UID是root的子进程。这样就可以对root权限进行控制,避免被恶意应用偷偷地使用。

            这里是su的源代码,小伙伴们可以根据上面所讲的知识读一读:https://code.google.com/p/superuser/source/browse/trunk/su/su.c?r=2

            在传统的UNIX以及类UNIX系统中,进程的权限只划分两种:特权和非特权。UID等于0的进程就是特权进程,它们可以通过一切的权限检查。UID不等于0的进程就非特权进程,它们在访问一些敏感资源或者调用一个敏感API时,需要进行权限检查。这种纯粹通过UID来做权限检查的安全机制来粗放了。于是,Linux从2.2开始,从进程的权限进行了细分,称为Capabilities。一个进程所具有Capabilities可以通过capset和prctl等系统API来设置。也就是说,当一个进程调用一个敏感的系统API时,Linux内核除了考虑它的UID之外,还会考虑它是否具有对应的Capability。

            这里就是Linux所设计的Capabilities列表,有兴趣的小伙伴可以再读一读:http://man7.org/linux/man-pages/man7/capabilities.7.html

            以上就是Linux基于UID/GID的安全机制的核心内容。接下来我们再看Android基于Permission的安全机制,它也有三个角色:apk、signature和permission,如图6所示:

    图6 Android的Permission安全机制

            

            Android的APK经过PackageManagerService安装之后,就相当于Linux里面的User,它们都会被分配到一个UID和一个主GID,而APK所申请的Permission就相当于是Linux里面的Supplementary GID。

            我们知道,Android的APK都是运行在独立的应用程序进程里面的,并且这些应用程序进程都是Zygote进程fork出来的。Zygote进程又是由init进程fork出来的,并且它被init进程fork出来后,没有被setuid降权,也就是它的uid仍然是root。按照我们前面所说的,应用程序进程被Zygote进程fork出来的时候,它的UID也应当是root。但是,它们的UID会被setuid修改为所加载的APK被分配的UID。

           参照Android应用程序进程启动过程的源代码分析一文的分析,ActivityManagerService在请求Zygote创建应用程序进程的时候,会将这个应用程序所加载的APK所分配得到的UID和GID(包括主GID和Supplementary GID)都收集起来,并且将它们作为参数传递给Zygote进程。Zygote进程通过执行函数来fork应用程序进程:

    [cpp] view plaincopy在CODE上查看代码片派生到我的代码片

    1. /* 
    2.  * Utility routine to fork zygote and specialize the child process. 
    3.  */  
    4. static pid_t forkAndSpecializeCommon(const u4* args, bool isSystemServer)  
    5. {     
    6.     pid_t pid;  
    7.       
    8.     uid_t uid = (uid_t) args[0];  
    9.     gid_t gid = (gid_t) args[1];  
    10.     ArrayObject* gids = (ArrayObject *)args[2];  
    11.     ......  
    12.       
    13.     pid = fork();  
    14.       
    15.     if (pid == 0) {  
    16.         ......  
    17.           
    18.         err = setgroupsIntarray(gids);  
    19.         ......  
    20.           
    21.         err = setgid(gid);  
    22.         ......  
    23.           
    24.         err = setuid(uid);  
    25.         ......  
    26.     }     
    27.       
    28.     .....  
    29.       
    30.     return pid;  
    31. }     

            参数args[0]、args[1]和args[]保存的就是APK分配到的UID、主GID和Supplementary GID,它们分别通过setuid、setgid和setgroupsIntarray设置给当前fork出来的应用程序进程,于是应用程序进程就不再具有root权限了。

            那么,Signature又充当什么作用呢?两个作用:1. 控制哪些APK可以共享同一个UID;2. 控制哪些APK可以申请哪些Permission。

            我们知道,如果要让两个APK共享同一个UID,那么就需要在AndroidManifest中配置android:sharedUserId属性。PackageManagerService在安装APK的时候,如果发现两个APK具有相同的android:sharedUserId属性,那么它们就会被分配到相同的UID。当然这有一个前提,就是这两个APK必须具有相同的Signature。这很重要,否则的话,如果我知道别人的APK设置了android:sharedUserId属性,那么我也在自己的APK中设置相同的android:sharedUserId属性,就可以去访问别人APK的数据了。

            除了可以通过android:sharedUserId属性申请让两个APK共享同一个UID之外,我们还可以将android:sharedUserId属性的值设置为“android.uid.system”,从而让一个APK的UID设置为1000。UID是1000的用户是system,系统的关键服务都是运行在的进程的UID就是它。它的权限虽然不等同于root,不过也足够大了。我们可以通过Master Key漏洞来看一下有多大。

            Master Key漏洞发布时,曾轰动了整个Android界,它的具体情况老罗就不分析了,网上很多,这里是一篇官方的文章:http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/。现在就简单说说它是怎么利用的:

            1. 找到一个具有系统签名的APP,并且这个APP通过android:sharedUserId属性申请了android.uid.system这个UID。

            2. 通过Master Key向这个APP注入恶意代码。

            3. 注入到这个APP的恶意代码在运行时就获得了system用户身份。

            4. 修改/data/local.prop文件,将属性ro.kernel.qemu的值设置为1。

            5. 重启手机,由于ro.kernel.qemu的值等于1,这时候手机里面的adb进程不会被setuid剥夺掉root权限。

            6. 通过具有root权限的adb进程就可以向系统注入我们熟悉的su和superuser.apk,于是整个root过程完成。

            注意,第1步之所以要找一个具有系统签名的APP,是因为通过android:sharedUserId属性申请android.uid.system这个UID需要有系统签名,也就是说不是谁可以申请system这个UID的。另外,/data/local.prop文件的Owner是system,因此,只有获得了system这个UID的进程,才可以对它进行修改。

            再说说Signature与Permission的关系。有些Permission,例如INSTALL_PACKAGE,不是谁都可以申请的,必须要具有系统签名才可以,这样就可以控制Suppementary GID的分配,从而控制应用程序进程的权限。具有哪些Permission是具有系统签名才可以申请的,可以参考官方文档:http://developer.android.com/reference/android/Manifest.html,就是哪些标记为“Not for use by third-party applications”的Permission。

            了解了Android的Permission机制之后,我们就可以知道:

             1. Android的APK就相当于是Linux的UID。

             2. Android的Permission就相当于是Linux的GID。

             3. Android的Signature就是用来控制APK的UID和GID分配的。

             这就是Android基于Permission的安全机制与Linux基于UID/GID的安全机制的关系,概括来说,我们常说的应用程序沙箱就是这样的:

    图7 Android的Application Sandbox

            Android是一个基于Linux内核的移动操作系统。Linux是一个支持多用户的系统,系统中的文件的访问权限是通过用户ID(UID)和用户组ID(GID)来控制的。换句话说,就是Linux的安全机制是基于UID和GID来实现的。Android在Linux内核提供的基于UID和GID的安全机制的基础上,又实现了一套称为Permission的安全机制,如图1所示:

    图1 Linux的UID/GID安全机制与Android的Permission安全机制

            那么,这两个安全机制是如何对应起来的呢?

            我们首先看一下Linux基于UID和GID的安全机制,它包含三个基本角色:用户、进程和文件,如图2所示:

    图2 Linux基于UID/GID的安全机制的三个角色

            Linux中的每一个用户都分配有一个UID,然后所有的用户又按组来进划分,每一个用户组都分配有一个GID。注意,一个用户可以属于多个用户组,也就是说,一个UID可以对应多个GID。在一个用户所对应的用户组中,其中有一个称为主用户组,其它的称为补充用户组。

            Linux中的每一个文件都具有三种权限:Read、Write和Execute。这三种权限又按照用户属性划分为三组:Owner、Group和Other。如图3所示:

    图3 Linux的文件权限划分

            从图3就可以看出文件acct:1. 所有者为root,可读可写可执行;2. 所有者所属的主用户组为root,在这个组中的其它用户可读可执行;3. 其余的用户可读可执行。

            Linux中的每一个进程都关联有一个用户,也就是对应有一个UID,如图4所示:

    图4 Linux的进程

             由于每一个用户都对应有一个主用户组,以及若干个补充用户组,因此,每一个进程除了有一个对应的UID之外,还对应有一个主GID,以及若干个Supplementary GIDs。这些UID和GID就决定了一个进程所能访问的文件或者所能调用的系统API。例如,在图4中,PID为340的进程一般来说,就只能访问所有者为u0_a19的文件。

             一个进程的UID是怎么来的呢?在默认情况下,就等于创建它的进程的UID,也就是它的父进程的UID。Linux的第一个进程是init进程,它是由内核在启动完成后创建的,它的UID是root。然后系统中的所有其它进程都是直接由init进程或者间接由init进程的子进程来创建。所以默认情况下,系统的所有进程的UID都应该是root。但是实际情况并非如此,因为父进程在创建子进程之后,也就是在fork之后,可以调用setuid来改变它的UID。例如,在PC中,init进程启动之后,会先让用户登录。用户登录成功后,就对应有一个shell进程。该shell进程的UID就会被setuid修改为所登录的用户。之后系统中创建的其余进程的UID为所登录的用户。

            进程的UID除了来自于父进程之外,还有另外一种途径。上面我们说到,Linux的文件有三种权限,分别是Read、Wirte和Execute。其实还有另外一个种权限,叫做SUID。例如,我们对Android手机进行root的过程中,会在里面放置一个su文件。这个su文件就具有SUID权限,如图5所示:

    图5 su的SUID和SGID

            一个可执行文件一旦被设置了SUID位,那么当它被一个进程通过exec加载之后,该进程的UID就会变成该可执行文件的所有者的UID。也就是说,当上述的su被执行的时候,它所运行在的进程的UID是root,于是它就具有最高级别的权限,想干什么就干什么。

            与SUI类似,文件还有另外一个称为SGID的权限,不过它描述的是用户组。也就是说,一个可执行文件一旦被设置了GUID位,么当它被一个进程通过exec加载之后,该进程的主UID就会变成该可执行文件的所有者的主UID。

            现在,小伙伴们应该可以理解Android手机的root原理了吧:一个普通的进程通过执行su,从而获得一个具有root权限的进程。有了这个具有root权限的进程之后,就可以想干什么就干什么了。su所做的事情其实很简单,它再fork另外一个子进程来做真正的事情,也就是我们在执行su的时候,后面所跟的那些参数。由于su所运行在的进程的UID是root,因此由它fork出来的子进程的UID也是root。于是,子进程也可以想干什么就干什么了。

            不过呢,用来root手机的su还会配合另外一个称为superuser的app来使用。su在fork子进程来做真正的事情之前,会将superuser启动起来,询问用户是否允许fork一个UID是root的子进程。这样就可以对root权限进行控制,避免被恶意应用偷偷地使用。

            这里是su的源代码,小伙伴们可以根据上面所讲的知识读一读:https://code.google.com/p/superuser/source/browse/trunk/su/su.c?r=2

            在传统的UNIX以及类UNIX系统中,进程的权限只划分两种:特权和非特权。UID等于0的进程就是特权进程,它们可以通过一切的权限检查。UID不等于0的进程就非特权进程,它们在访问一些敏感资源或者调用一个敏感API时,需要进行权限检查。这种纯粹通过UID来做权限检查的安全机制来粗放了。于是,Linux从2.2开始,从进程的权限进行了细分,称为Capabilities。一个进程所具有Capabilities可以通过capset和prctl等系统API来设置。也就是说,当一个进程调用一个敏感的系统API时,Linux内核除了考虑它的UID之外,还会考虑它是否具有对应的Capability。

            这里就是Linux所设计的Capabilities列表,有兴趣的小伙伴可以再读一读:http://man7.org/linux/man-pages/man7/capabilities.7.html

            以上就是Linux基于UID/GID的安全机制的核心内容。接下来我们再看Android基于Permission的安全机制,它也有三个角色:apk、signature和permission,如图6所示:

    图6 Android的Permission安全机制

            

            Android的APK经过PackageManagerService安装之后,就相当于Linux里面的User,它们都会被分配到一个UID和一个主GID,而APK所申请的Permission就相当于是Linux里面的Supplementary GID。

            我们知道,Android的APK都是运行在独立的应用程序进程里面的,并且这些应用程序进程都是Zygote进程fork出来的。Zygote进程又是由init进程fork出来的,并且它被init进程fork出来后,没有被setuid降权,也就是它的uid仍然是root。按照我们前面所说的,应用程序进程被Zygote进程fork出来的时候,它的UID也应当是root。但是,它们的UID会被setuid修改为所加载的APK被分配的UID。

           参照Android应用程序进程启动过程的源代码分析一文的分析,ActivityManagerService在请求Zygote创建应用程序进程的时候,会将这个应用程序所加载的APK所分配得到的UID和GID(包括主GID和Supplementary GID)都收集起来,并且将它们作为参数传递给Zygote进程。Zygote进程通过执行函数来fork应用程序进程:

    [cpp] view plaincopy在CODE上查看代码片派生到我的代码片

    1. /* 
    2.  * Utility routine to fork zygote and specialize the child process. 
    3.  */  
    4. static pid_t forkAndSpecializeCommon(const u4* args, bool isSystemServer)  
    5. {     
    6.     pid_t pid;  
    7.       
    8.     uid_t uid = (uid_t) args[0];  
    9.     gid_t gid = (gid_t) args[1];  
    10.     ArrayObject* gids = (ArrayObject *)args[2];  
    11.     ......  
    12.       
    13.     pid = fork();  
    14.       
    15.     if (pid == 0) {  
    16.         ......  
    17.           
    18.         err = setgroupsIntarray(gids);  
    19.         ......  
    20.           
    21.         err = setgid(gid);  
    22.         ......  
    23.           
    24.         err = setuid(uid);  
    25.         ......  
    26.     }     
    27.       
    28.     .....  
    29.       
    30.     return pid;  
    31. }     

            参数args[0]、args[1]和args[]保存的就是APK分配到的UID、主GID和Supplementary GID,它们分别通过setuid、setgid和setgroupsIntarray设置给当前fork出来的应用程序进程,于是应用程序进程就不再具有root权限了。

            那么,Signature又充当什么作用呢?两个作用:1. 控制哪些APK可以共享同一个UID;2. 控制哪些APK可以申请哪些Permission。

            我们知道,如果要让两个APK共享同一个UID,那么就需要在AndroidManifest中配置android:sharedUserId属性。PackageManagerService在安装APK的时候,如果发现两个APK具有相同的android:sharedUserId属性,那么它们就会被分配到相同的UID。当然这有一个前提,就是这两个APK必须具有相同的Signature。这很重要,否则的话,如果我知道别人的APK设置了android:sharedUserId属性,那么我也在自己的APK中设置相同的android:sharedUserId属性,就可以去访问别人APK的数据了。

            除了可以通过android:sharedUserId属性申请让两个APK共享同一个UID之外,我们还可以将android:sharedUserId属性的值设置为“android.uid.system”,从而让一个APK的UID设置为1000。UID是1000的用户是system,系统的关键服务都是运行在的进程的UID就是它。它的权限虽然不等同于root,不过也足够大了。我们可以通过Master Key漏洞来看一下有多大。

            Master Key漏洞发布时,曾轰动了整个Android界,它的具体情况老罗就不分析了,网上很多,这里是一篇官方的文章:http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/。现在就简单说说它是怎么利用的:

            1. 找到一个具有系统签名的APP,并且这个APP通过android:sharedUserId属性申请了android.uid.system这个UID。

            2. 通过Master Key向这个APP注入恶意代码。

            3. 注入到这个APP的恶意代码在运行时就获得了system用户身份。

            4. 修改/data/local.prop文件,将属性ro.kernel.qemu的值设置为1。

            5. 重启手机,由于ro.kernel.qemu的值等于1,这时候手机里面的adb进程不会被setuid剥夺掉root权限。

            6. 通过具有root权限的adb进程就可以向系统注入我们熟悉的su和superuser.apk,于是整个root过程完成。

            注意,第1步之所以要找一个具有系统签名的APP,是因为通过android:sharedUserId属性申请android.uid.system这个UID需要有系统签名,也就是说不是谁可以申请system这个UID的。另外,/data/local.prop文件的Owner是system,因此,只有获得了system这个UID的进程,才可以对它进行修改。

            再说说Signature与Permission的关系。有些Permission,例如INSTALL_PACKAGE,不是谁都可以申请的,必须要具有系统签名才可以,这样就可以控制Suppementary GID的分配,从而控制应用程序进程的权限。具有哪些Permission是具有系统签名才可以申请的,可以参考官方文档:http://developer.android.com/reference/android/Manifest.html,就是哪些标记为“Not for use by third-party applications”的Permission。

            了解了Android的Permission机制之后,我们就可以知道:

             1. Android的APK就相当于是Linux的UID。

             2. Android的Permission就相当于是Linux的GID。

             3. Android的Signature就是用来控制APK的UID和GID分配的。

             这就是Android基于Permission的安全机制与Linux基于UID/GID的安全机制的关系,概括来说,我们常说的应用程序沙箱就是这样的:

    图7 Android的Application Sandbox

    展开全文
  • android系统安全机制

    2013-08-13 09:07:01
    android系统安全机制.pptx
  • Android是Google公司推出的手机操作系统。近几年,Android操作系统的...本文在分析安卓操作系统基本构架的基础上, 介绍并分析了Android现有的安全机制以及安全隐患, 并针对安卓操作系统现有的安全隐患提出相应解决措施。
  • Android 系统安全机制之Apk签名详解

    引言

    在进行 Android 应用开发的时候,尤其是开发的是系统应用,就需要有系统签名才能正常运行。对于开发ROM来说,我们开发的App一般是放到系统代码库中跟随系统一起编译为系统应用的,编译时会通过源码里的脚本自动进行签名。如果想要用 Android Studio 单独对某个开发的应用进行签名的话,必须需要使用和Android 系统一模一样的签名文件,这是Android 安全机制的方面之一。同时这也是开发ROM固件时App 一般都是使用源码中编译方式,而很少直接使用使用 IDE 编译,然后 push 到 /system/app/或者/system/priv-app/下,然后adb reboot的原因之一(当然如果你push 的是使用系统keysotre文件签名的apk 是完全ok的,最好把xxx目录下的ota文件夹删除)。

    Android系统禁止更新安装签名不一致的APK,另外如果应用还需要使用system权限,必须保证Apk签名与Android 系统签名一致且在 AndroidManifest.xml 清单文件的manifest节点下声明:android:sharedUserId=“android.uid.system”

    以后更多精选系列文章以高度完整的系列形式发布在公众号,真正的形成一套完整的技术栈,欢迎关注,目前第一个系列是关于Android系统启动系列的文章,大概有二十几篇干货:
    在这里插入图片描述

    一、Android 签名机制

    截至目前为止Android中一共提供了三种应用签名方案:

    • V1——基于JAR签名,v1 签名保护的是APK 压缩包下的所有文件(只要原来的文件的签名信息校验通过就认为合法),但是如果在原有APK 压缩包里添加文件是不影响校验的(而删除文件是影响的)
    • v2+——搭载 Android 7.0 及更高版本的设备支持 APK 签名方案 v2(v2 方案)及更高版本的方案(在 Android 9 中,v2 方案已更新为 v3 方案,以便在签名分块中包含其他信息,但在其他方面保持相同的工作方式)。该方案会对 APK 的内容进行哈希处理和签名,然后将生成的“APK 签名分块”插入到 APK 中。在验证期间,v2+ 方案会将 APK 文件视为 blob,并对整个文件进行签名检查。对 APK 进行的任何修改(包括对 ZIP 元数据进行的修改)都会使 APK 签名作废。这种形式的 APK 验证不仅速度要快得多,而且能够发现更多种未经授权的修改。新的签名格式向后兼容,因此,使用这种新格式签名的 APK 可在更低版本的 Android 设备上进行安装(会直接忽略添加到 APK 的额外数据),但前提是这些 APK 还带有 v1 签名。
      在这里插入图片描述
      为了保持与 v1 APK 格式的向后兼容性,v2 和 v3 APK 签名存储在“APK 签名分块”内紧邻 ZIP Central Directory 前面。v3 APK 签名分块的格式与 v2 相同。APK 的 v3 签名会存储为一个“ID-值”对,其中 ID 为 0xf05368c0。v3 方案的设计与 v2 方案非常相似,它们采用相同的常规格式,并支持相同的签名算法 ID、密钥大小和 EC 曲线。但是,v3 方案增添了有关受支持的 SDK 版本和 proof-of-rotation 结构的信息。v3 在 APK 签名分块中添加了有关受支持的 SDK 版本和 proof-of-rotation 结构的信息。

    1、生成密钥对keystore

    默认情况下直接通过Android Studio在Run或Debug时,会使用默认的C:\Users\用户名.android\debug.keystore密钥库对App签名:

    密钥库名——debug.keystore
    密钥别名——androiddebugkey
    密钥库密码——android

    JDK 自带的keytool工具,执行以下指令

    位于\jdk1.8.0_91\bin

    keytool -genkeypair -keystore 密钥库名字及存储位置 -alias 密钥别名 -validity 有效天数 -keyalg RSA
    

    其中别名作用在于当密钥库可以存在多个密钥对,可以区分不同密钥对,算法只支持RAS和DSA 。因为可重复使用此命令,在同一密钥库中创建多条密钥对,例如在 debug.keystore 中新增一对密钥,别名是cmo

    keytool -genkeypair -keystore debug.keystore -alias cmo -validity 3600
    

    创建完毕后,可以查看密钥对信息

    keytool -v -list -keystore keystore文件路径
    

    keytool 工具支持的命令行参数:

    在这里插入图片描述

    2、Android 签名V1

    JDK自带的jarsigner 是针对jar包签名的通用工具,也是Android 早期使用的签名工作,即V1。

    jarsigner位于 JAVA_HOME/bin/jarsigner.exe,从JDK7开始, jarsigner默认算法是SHA256, 但Android 4.2以下不支持该算法。

    在进行V1签名时jarsigner.exe会对压缩包里的每个文件(除了META-INF 文件)进行验证并生成SHA1指纹,V1签名是对压缩包中单个文件逐一进行签名验证,签名后还能对压缩包修改(移动/重新压缩文件)。无论是 apk 包,还是 jar 包,本质上都是一样的,都是压缩文件。因此它们的签名过程都大同小异(仅限V1签名),V1签名本质就是给Apk的文件里,增加一些校验信息(即MATA-INF文件夹里的一些文件),所以Apk压缩文件里的MATA-INF保存着有三个文件:MANIFEST.MF、CERT.SF和CERT.RSA

    • MANIFEST.MF——Framework 遍历Apk包中的所有文件(entry),对非文件夹非签名文件的文件(图片、资源xml、so、.dex)逐个生成SHA1的数字签名信息,再用Base64进行编码之后将生成的签名写入MANIFEST.MF文件,即保存所有文件的 SHA1 指纹(除了 META-INF 文件)。

    SHA1数字签名——一种安全哈希算法,类似于MD5算法,可以把任意长度的输入,通过散列算法变成固定长度的输出(即“摘要”)即每个文件都对应一个SHA256的数字签名,经过Base64 编码后得到cert.sf文件。但仅依赖这个摘要信息不能复原原来的信息且不同信息的摘要互不相同。因此,如果原Apk的文件被改变了,那么在Apk安装校验时,改变后的文件摘要信息与MANIFEST.MF的检验信息不同导致安装失败。
    部分结构如下图:
    在这里插入图片描述

    • CERT.SF——对前一步生成的MANIFEST.MF,使用SHA1-RSA算法,用私钥进行签名,其中的值是对清单文件里的SHA256 再进行SHA256 后再次Base64得到

    RSA是一种非对称加密算法。用私钥通过RSA算法对摘要信息进行加密。在安装时只能使用公钥才能解密它。解密之后,将它与未加密的摘要信息进行对比,如果相符,则表明内容没有被异常修改

    • CERT.RAS——生成MANIFEST.MF没有使用密钥信息,而生成CERT.SF文件使用了私钥文件。CERT.RSA文件中保存了公钥、所采用的加密算法等信息 ,Framework会解析这个RAS文件。

    其实Android Studio 或者其他打包Apk的软件本质上都是通过执行jarsigner指令:

    jarsigner -keystore 密钥库名 xxx.apk 密钥别名
    //兼容android 4.1以下
    jarsigner -keystore 密钥库名 -digestalg SHA1 -sigalg SHA1withRSA xxx.apk 密钥别名
    
    jarsigner -keystore debug.keystore -digestalg SHA1 -sigalg SHA1withRSA app.apk mydebugkey
    

    若密钥库中有多个密钥对,则必须指定密钥别名。

    3、Android 签名V2+

    apksigner 是Google 官方提供的针对 Android apk 签名及验证的专用工具,默认同时使用V1和V2签名,以兼容 Android7.0以下系统版本,即V2。

    apksigner 位于 Android SDK/build-tools/SDK 版本 /apksigner.bat

    apksigner是对 zip 压缩包的整个文件验证,签名后不能修改压缩包(包括 zipalign ),因此
    签名更安全(不能修改压缩包且签名验证时间更短(不需要解压验证),因此安装速度更快

    apksigner sign --ks 密钥库名 --ks-key-alias 密钥别名 xxx.apk
    
    //禁用v2
    apksigner sign --v2-signing-enabled false --v1-signing-enabled true --ks 密钥库名 xxx.apk
    
    apksigner sign --v1-signing-enabled false --ks debug.keystore --ks-key-alias mydebugkey app.apk
    

    若密钥库中有多个密钥对,则必须指定密钥别名

    4、zipalign 、V1、V2+签名

    zipalign位于android-sdk/build-tools目录下,主要对APK进行对齐处理,对齐的主要过程是将APK包中所有的资源文件距离文件起始偏移为4字节整数倍,这样通过内存映射访问apk文件时的速度会更快,对齐的作用就是减少运行时内存的使用,如果要上传到Google Play必须进行对齐操作。

    zipalign -v -p 4 demo_unsigned.apk demo_signed.apk
    zipalign -c -v 4 demo_unsigned.apk //检查 APK 是否对齐
    

    需要注意的是zipalign 可以在V1签名后执行,但 zipalign 不能在V2签名之后执行,只能在V2签名之前执行

    5、签名的校验

    如果想对一个APK 检验是否已经签名成功,不同的版本使用的工具不一样。当Android 系统版本在7.0以上是时默认编译打包的时候会使用v2 签名,同时存在v1 和v2 时会优先校验v2。

    5.1、对V1进行校验

    首先最简单的上就是使用JDK 自带的keytool工具

    位于\jdk1.8.0_91\bin

    keytool -printcert -jarfile xxxx.apk 
    

    在这里插入图片描述
    还可以通过Android Studio 自带的“Analyze Apk ”功能可以直接打开并分析apk的组成,也可以直接在AS 里双击apk或者把外部的apk拖到AS里,一般apk 签名成功之后就会在apk包下的MATA-INF保存着签名文件CERT.RSA和CERT.SF,如果没有这个文件说明没有进行签名

    默认情况下AS 的assemble gradle task 是不会进行签名的,即使配置了singingConfigs

    通过keytool工具查看 /MATA-INF/CERT.RSA文件

    keytool -printcert -file META-INF/CERT.RSA
    

    简而言之,v1检验是基于 /MATA-INF/MANIFEST.MF文件的,Framework 会在安装APK时候判断你有没有签名,如果签名版本是V1则会去遍历 /MATA-INF/MANIFEST.MF文件,逐一去校验数字签名信息和当前安装包里文件的数字签名信息。

    5.2、对V2+ 进行校验

    在这里插入图片描述

    apksigner verify -v --print-certs xxxx.apk
    

    简而言之,v2+ 签名是在原有ZIP文件格式的基础上,插入一个签名分块区域,记录签名信息。

    6、Android 签名的作用

    • Android签名机制其实是对Apk包完整性和发布机构唯一性的一种校验机制。
    • Android签名机制不能阻止Apk包被修改,但修改后的再签名无法与原先的签名保持一致。(拥有私钥的情况除外)。
    • Apk包加密的公钥就打包在Apk包内,且不同的私钥对应不同的公钥。换言之,不同的私钥签名的Apk公钥也必不相同。所以可以根据公钥的对比,来判断私钥是否一致

    7、签名版本的选择

    根据项目灵活地选择V1和V2版本签名,可以在一定程度上让你的APK瘦身成功,简而言之,V1就是在原有的压缩包里META-INF生成签名文件,而V2则是向整个压缩包文件按照固定格式插入字节码数据。

    • 只进行V2签名的APK只能运行于Android API 大于等于7.0的设备上。
    • 只进行V1签名可以运行全版本
    • 同时进行V1和V2签名也可以运行全版本,更安全但压缩包也相对来说最大。

    8、Apk安装签名解析

    Android系统安装程序肯定会获取APK信息进行比对,所以]可以通过Android源码获得一些思路和帮助。Apk安装是PackageParser负责解析安装包,PackageParser负责AndroidManifest(applicationInfo、Version、mSharedUserId、permissions、四大组件等)、签名读取解析

        public Package parsePackage(File packageFile, int flags, boolean useCaches)
                throws PackageParserException {
            Package parsed = useCaches ? getCachedResult(packageFile, flags) : null;
            if (parsed != null) {
                return parsed;
            }
    
            long parseTime = LOG_PARSE_TIMINGS ? SystemClock.uptimeMillis() : 0;
            if (packageFile.isDirectory()) {
                parsed = parseClusterPackage(packageFile, flags);
            } else {
                parsed = parseMonolithicPackage(packageFile, flags);
            }
    
            long cacheTime = LOG_PARSE_TIMINGS ? SystemClock.uptimeMillis() : 0;
            cacheResult(packageFile, flags, parsed);
            if (LOG_PARSE_TIMINGS) {
                parseTime = cacheTime - parseTime;
                cacheTime = SystemClock.uptimeMillis() - cacheTime;
                if (parseTime + cacheTime > LOG_PARSE_TIMINGS_THRESHOLD_MS) {
                    Slog.i(TAG, "Parse times for '" + packageFile + "': parse=" + parseTime
                            + "ms, update_cache=" + cacheTime + " ms");
                }
            }
            return parsed;
        }
    

    篇幅问题不再展开,未完待续…

    /frameworks/base/core/java/android/content/pm/PackageParser.java

    二、用 platform.pk8 和 platform.x509.pem 生成 keystore 系统签名文件

    如果想要用 Android Studio 单独对某个开发的应用使用Android系统keystore文件进行签名的话,首先得自己获取系统keystore文件,Android 中不同的system 权限使用不同的keystore,每个密钥都包含两个文件:扩展名为 .x509.pem 的证书和扩展名为 .pk8 的私钥。私钥需要加以保密,并用于对 apk 包进行签名。密钥本身也可能受密码保护。而证书只包含公开的一半密钥,因此可以大范围地分发,证书被用于验证某个 apk 包是否由相应的私钥进行签名。标准 Android 版本使用四个密钥,所有这些密钥都位于 build/target/product/security 中:

    • testkey(testkey.pk8)——适用于未另外指定密钥的 apk 包的通用默认密钥。
    • 平台(platform.pk8)——适用于核心平台所包含的 apk 包的测试密钥。
    • 共享(shared.pk8)——适用于家庭/联系人进程中的共享内容的测试密钥。
    • 媒体(media.pk8)——适用于媒体/下载系统所包含的 apk 包的测试密钥

    通过系统的 .pk8 和 .x509.pem 转换成为我们可以直接使用的 keystore 文件,而将.x509.pem 和.pk8导入keystore文件、或者.jks文件,需要openssl工具 、密钥和证书管理工具keytool ,并配置好环境变量

    1、在源码的/build/target/product/security下获取platform.pk8 和 platform.x509.pem

    platform.pk8 和 platform.x509.pem 存在于源码项目里/build/target/product/security/下。

    Android 使用公开指数为 3 的 2048 位 RSA 密钥即.pk8,可以使用 openssl.org 提供的 openssl 工具来生成证书/私钥对:

    • generate RSA key
    openssl genrsa -3 -out crazymo.pem 2048
    
    • create a certificate with the public part of the key 创建证书
    openssl req -new -x509 -key crazymo.pem -out crazymo.x509.pem -days 1000000 -subj '/C=CN/ST=ZJ/L=SH/O=crazymo, Inc./OU=crazymo Mobility/CN=crazymo/emailAddress=crazymo@google.com'
    
    • create a PKCS#8-formatted version of the private key 创建 .pk8

    openssl pkcs8 命令可创建一个适用于该版本系统的 .pk8 文件

    //未设置密码
    openssl pkcs8 -in crazymo.pem -topk8 -outform DER -out crazymo.pk8 -nocrypt
    或者
    //需要设置密码
    openssl pkcs8 -in crazymo.pem -topk8 -outform DER -out crazymo.pk8 -passout stdin
    

    2、openssl把pkcs8格式的私钥转化成pkcs12格式

    openssl pkcs8 -in platform.pk8 -inform DER -outform PEM -out shared.priv.pem -nocrypt
    

    3、openssl 把x509.pem公钥转换成pkcs12格式

    需要输入密码:android

    openssl pkcs12 -export -in platform.x509.pem -inkey     shared.priv.pem -out shared.pk12 -name androiddebugkey
    

    4、生成platform.keystore

    keytool -importkeystore -deststorepass android -destkeypass android -destkeystore platform.keystore -srckeystore shared.pk12 -srcstoretype PKCS12 -srcstorepass android -alias androiddebugkey
    

    如果没有使用系统原生的keystore签名文件进行签名,即使你的申请system权限的Apk本身没有问题且也使用其他keystore进行了正确的签名安装到一些ROM会导致以下错误。

    Y:\MoVoice>adb install -r MoAIVoiceService.apk
    Performing Streamed Install
    adb: failed to install MoAIVoiceService.apk: Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES: Packag
    e /data/app/vmdl428612103.tmp/base.apk has no certificates at entry AndroidManifest.xml]
    

    [ INSTALL_PARSE_FAILED_NO_CERTIFICATES : Packag
    e /data/app/vmdl428612103.tmp/base.apk has no certificates at entry AndroidManifest.xml]

    三、使用系统keystore对App 进行签名

    无论是何种keystore,都可以用两种形式对App 进行签名。

    1、利用SDK 自带的signapk.jar和platform.pk8 与platform.x509.pem 进行签名

    signapk.jar位于/prebuilts/sdk/tools/lib

    为了方便把签名证书platform.pk8platform.x509.pem 签名工具signapk.jar 放置在同一个文件夹,然后执行以下指令通过signapk.jar可执行包,以platform.x509.pem证书文件platform.pk8私钥文件源.apk进行签名,签名后的文件保存为目标.apk

    1.1、 windows环境下

    java -jar signapk.jar platform.x509.pem platform.pk8 源.apk 目标.apk
    
    • 源.apk——预进行签名的Apk ,指的是你将要使用系统签名文件的源Apk,需要替换为你自己Apk的名称
    • 目标.apk——签名成功后的Apk

    1.2、 Ubuntu 编译环境执行

    java -jar out/host/linux-x86/framework/signapk.jar build/target/product/security/platform.x509.pem build/target/product/security/platform.pk8 预进行签名.apk 签名后.apk
    

    2、通过Android Studio 进行签名

    通过Android Studio 工具栏Build——>Generate Signed Bundle or APK
    在这里插入图片描述
    选择APK
    在这里插入图片描述
    然后Next——>Finish。

    四、 Android自定义系统签名制作介绍(覆盖模式)

    1、系统中有4组key用于build阶段对apk进行签名:

    • Media
    • Platform
    • Shared
    • Testkey

    default key是放在Android源码的/build/target/product/security目录下:

    • media.pk8与media.x509.pem;
    • platform.pk8与platform.x509.pem;
    • shared.pk8与shared.x509.pem;
    • testkey.pk8与testkey.x509.pem;

    其中,*.pk8文件为私钥,*.x509.pem文件为公钥,这需要去了解非对称加密方式。

    可以在apk的android.mk文件中会指定LOCAL_CERTIFICATE 变量:
    • LOCAL_CERTIFICATE := testkey ——普通APK,默认情况下使用
    • LOCAL_CERTIFICATE := platform —— 该APK完成一些系统的核心功能,这种方式编译出来的APK所在进程的UID为system
    • LOCAL_CERTIFICATE := shared ——该APK是media/download系统中的一环
    • LOCAL_CERTIFICATE := media —— 该APK是media/download系统中的一环

    如果不指定,默认使用testkey。对应的,除了在Android.mk指定上述的值,还需要在APK源码的AndroidManifest.xml文件的manifest节点里面申明权限:

    • android:sharedUserId=“android.uid.system”
    • android:sharedUserId=“android.uid.shared”
    • android:sharedUserId=“android.media”
    Build规则是Build/core/prebuilt.mk。在build/core/config.mk中,DEFAULT_SYSTEM_DEV_CERTIFICATE可以通过PRODUCT_DEFAULT_DEV_CERTIFICATE去指定各家厂商的key path。

    2、签名生成

    Android源码提供了自定义系统签名的工具(/development/tools)make_key,使用如下命令

    development/tools/make_key testkey  '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com'
    

    可以生成testkey.pk8、testkey.x509.pem公私钥 ,其中第一个参数(testkey)是需要生成的签名名称,第二个参数是公司信息。

    代号说明
    C国家 (2 letter code)
    ST省 (full name)
    L城市 (eg, city)
    O组织 (eg, company)
    OU部门 (eg, section)
    CN通用名称 (eg, your name or your server’s hostname)
    emailAddress邮箱

    3、签名覆盖

    最后可以使用:openssl pkcs8 -inform DER -nocrypt -in testkey.pk8 -out testkey.pem导出私钥信息,将生成的签名文件(秘钥对)copy到build/targets/product/security/目录下即可。

    五、Android Studio 调试签名Apk

    首先在Module下的build.gradle脚本里配置,这样子通过Android Studio在Run或Debug时,就会使用你配置的keystore。

    默认情况下Android Studio 的assemble gradle task 是不会进行签名的,即使配置了singingConfigs,所以如果要打包签名APK 最好直接通过Android Studio 的图形界面。

    android{
    	...
    	signingConfigs {
    		releae {
                storeFile file('Z:\\MoCode\\Keystore\\platform.keystore')
                storePassword 'android'
                keyAlias 'platform'
                keyPassword 'android'
            }
            debug {
                storeFile file('Z:\\MoCode\\Keystore\\debug.keystore')
                storePassword 'android'
                keyAlias 'debug'
                keyPassword 'android'
            } 
        }
    	...
    }
    

    这样配置后再通过Android Studio Run或者Debug进行安装,就可以会通过配置的签名文件进行签名并自动安装到设备上(若一般我们的服务是没有activity的话,还需要设置Luncher 为nothing)。最后附一个 Android 原生的platform 权限所用的签名文件

    展开全文
  • Android开发中,很多时候我们需要用到进程间通信,所谓进程间通信,实现进程间通信的机制有很多种,比如说socket、pipe等,Android中进程间通信的方式主要有三种: 1.标准Linux Kernel IPC 接口; 2.标准D-BUS接口...
  • Android操作系统安全机制研究.pdf
  • 安卓终端系统安全机制研究与设计.pdf
  • Android安全机制探讨

    2021-02-26 01:43:01
    Android市场繁荣的同时存在的,是Android安全问题日益突出,各种隐私泄露,信息丢失,恶意扣费,系统入侵屡见不鲜。针对Android安全的研究十分紧迫和必要。Android安全范畴主要包括硬件、通信、软件、信息四大方面...
  • Android进阶-Android系统信息与安全机制Android系统信息获取、Apk信息获取、以及安全机制
  • Android移动智能终端操作系统安全机制的安全性评估.pdf
  • 在全球信息化的普及和移动互联网蓬勃发展的背景下,安卓系统安全加固作为移动互联网和智能终端的新兴领域最为核心的技术之一,需要结合其所表现出来的安全问题进行深入的分析与研究。结合了证书链机制,以完整性...
  • Android操作系统安全机制研究.pdf
  • Android移动智能终端操作系统安全机制的安全性评估.rar
  • 移动用户的多场景使用方式对数据安全和隐私保护的要求很高,为解决这一问题,该文研究了智能移动设备的多系统安全机制,提出并实现了多Android操作系统快速切换的系统原型。该原型系统利用操作系统的挂起/唤醒机制,...
  • Android是业界流行的开源移动平台,受到广泛关注并为多个手机制造商作为手机的操作系统平台,因此,研究其安全架构及权限控制机制具有非常的重要性。本文从Android层次化安全架构入手,详细地介绍Android平台的...
  • 基于证书链验证机制的智能终端安卓系统安全加固方案.pdf
  • 基于安全域的Android系统内核安全增强机制研究.pdf
  • Android系统信息与安全机制

    千次阅读 多人点赞 2019-02-16 09:50:20
    今天和大家分享一下—Android系统信息与安全机制–1、安卓系统信息的获取/********************设备配置信息相关********************//** *主板 */ publicstaticfinalStringBUILD_BOARD=Build.B
  • 基于Android安全机制的权限控制系统.pdf
  • 基于Android安全机制的权限检测系统.pdf
  • 基于Android系统密钥漏洞的安全机制分析.pdf
  • 进程和进程边界.mp4

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 79,543
精华内容 31,817
关键字:

安卓系统的安全机制