KR20170088858A - 애플리케이션 무결성 검증을 제공하기 위한 방법 및 디바이스 - Google Patents

애플리케이션 무결성 검증을 제공하기 위한 방법 및 디바이스 Download PDF

Info

Publication number
KR20170088858A
KR20170088858A KR1020177014266A KR20177014266A KR20170088858A KR 20170088858 A KR20170088858 A KR 20170088858A KR 1020177014266 A KR1020177014266 A KR 1020177014266A KR 20177014266 A KR20177014266 A KR 20177014266A KR 20170088858 A KR20170088858 A KR 20170088858A
Authority
KR
South Korea
Prior art keywords
checksum
application
code
signed
modified
Prior art date
Application number
KR1020177014266A
Other languages
English (en)
Inventor
샤를 살몽-레가뇌
모하메드 칼루미
Original Assignee
톰슨 라이센싱
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 톰슨 라이센싱 filed Critical 톰슨 라이센싱
Publication of KR20170088858A publication Critical patent/KR20170088858A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/64—Self-signed certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

디바이스 (110) 는 애플리케이션에 대한 APK 파일을 다운로드하여 설치하고 (S204), 그 동안 코드가 수정된다. 수정된 코드에 대한 체크섬은 신뢰 엔티티 (130) 로 전송되고 (S206), 이것은 수신된 체크섬이 애플리케이션에 대한 저장된 체크섬과 매칭하는지를 체크한다 (S208). 그렇다면, 수신된 체크섬은 서명 (S210) 되고, 디바이스 (110) 로 반환 (S212) 되고 여기에 그것이 저장 (S214) 된다. 다음으로, 디바이스는 서명된 체크섬과 비교되는 수정된 코드에 대한 체크섬을 계산함으로써 수정된 코드의 무결성을 체크 (S216) 할 수 있다. 이 솔루션은, 설치 동안의 DEX가 인증된 체크섬이 없는 ODEX 에 최적화되어 있기 때문에, 안드로이드 OS 를 사용하는 디바이스들에 특히 적합하다.

Description

애플리케이션 무결성 검증을 제공하기 위한 방법 및 디바이스{METHOD AND DEVICE FOR PROVIDING VERIFYING APPLICATION INTEGRITY}
본 개시는 일반적으로 컴퓨터 시스템에 관한 것이고, 특히 이러한 시스템에서 소프트웨어 코드의 무결성에 관한 것이다.
이 섹션은, 이하에 기술되거나 및/또는 청구되는 본 개시의 다양한 양태와 관련될 수도 있는, 기술의 다양한 양태를 독자에게 소개하고자 의도된다. 이 논의는 본 개시의 다양한 양태들에 대한 더 나은 이해를 쉽게하기 위한 배경 정보를 독자에게 제공하는데 도움이 될 것으로 생각된다. 따라서, 이러한 진술은 이러한 관점에서 읽혀져야 하며, 선행 기술의 인정으로서 읽혀져서는 안된다는 점을 이해해야 한다.
다양한 이유로, 처리 디바이스가 변조되지 않은 소프트웨어를 실행하도록 보장하는 것이 종종 바람직하다. 이를 위해, 소프트웨어 이미지를 변조 공격 (tampering attack) 으로부터 보호하기 위해 다양한 기술들을 사용할 수 있다. 가장 일반적인 기술은 코드 세그먼트들에 대해 서명 (signature) 또는 체크섬 (checksum) 을 계산한 다음, 나중 단계에서 서명 또는 체크섬을 검증하는 것이다. 체크섬은 일반적으로 시크릿 (secret) 없이 계산되고 검증되는 반면, 암호화 서명의 생성은 개인 키 (private key) 를 필요로 하고 서명의 검증 (verification) 은 대응하는 공개 키 (public key) 를 필요로 한다.
체크섬 기반 보호의 일례는 Windows 운영 시스템에서 사용되는 PE (Portable Executable) 형식을 위한 CRC32 이다. PE 헤더는 대응하는 코드 섹션의 체크섬을 제공하는 CRC32 필드를 포함한다. 보호를 성공적으로 우회하기 위해, 공격자는 먼저 코드 섹션을 수정 한 다음, 원래 체크섬을 수정된 코드 섹션을 통해 계산된 새로운 값으로 교체한다. 이 유형의 공격은 공격자가 수정된 코드 섹션들의 체크섬을 업데이트하기 위해 시크릿을 필요로 하지 않기 때문에 가능합니다.
체크섬의 약점을 고려할 때, 암호화 서명이 바람직한 솔루션이다. 서명의 생성은 코드 릴리스 전에 수행되며 개인 (및 따라서 시크릿) 키를 사용한다. 연관된 공개 키는 코드에 부가되고 나중에 코드의 설치시 또는 런타임시 코드 무결성을 체크하는데 사용된다. 공격자는 여전히 코드를 수정할 수 있지만, 개인 키가 없으면 코드에 대한 올바른 서명을 생성할 수 없기 때문에, 공격은 실패한다.
Arxan (GuardIT™), Metaforic (Metafortress™) 등이 제공하는 솔루션과 같이 네이티브 코드 (native code) 에서 전달되고 실행되는 애플리케이션의 무결성을 체크하기 위한 많은 솔루션들이 존재한다. 네이티브 코드는 프로세서에 의해 직접 실행가능한 어셈블러 명령 세트이다. 설치 후 명령 세트는 변경되지 않는데, 이는 프로그램 무결성 값이 설치 전과 후에 동일하게 유지된다 (즉, 경시적으로 일정하게 유지된다) 는 것을 의미한다. 이 경우, 서명을 미리 생성하여 애플리케이션 패키지와 함께 전달할 수 있다.
반면에, 해석된 코드- 이를테면 Java, 안드로이드 DEX 코드 등으로 작성된 코드-형태로 배포되는 애플리케이션은, 실행되기 전에 인터프리터를 통해 통과되야 하는 중간 명령들을 포함한다. 네이티브 코드와 달리, 해석된 코드는 설치시 후에 최적화 목적으로 수정될 수 있다. 코드 수정은 일반적으로 타겟 플랫폼에 크게 의존하므로 반드시 예측가능한 것은 아니다. 코드가 수정되면, 해석된 코드 상에 생성된 서명을 사용하여 런타임 시에 동적으로 코드 무결성과 진정성 (authenticity) 을 체크할 수 없다.
앞서 언급된 안드로이드 운영 시스템 상에 애플리케이션 소프트웨어를 배포하고 설치하기 위해, APK - Android Application PacKage -라 불리는 파일 형식이 사용된다. APK 파일을 만들기 위해, 먼저 안드로이드 용 프로그램을 중간 언어로 컴파일한 다음, 그의 부분들을 압축된 아카이브 파일 (ZIP 형식) 로 패키지화한다. 아카이브 파일은 단일 DEX (Dalvik EXecutable code) 파일, 다양한 리소스 (예 : 이미지 파일), 및 APK 파일의 매니페스트 (manifest) 에 전체 프로그램 코드를 포함한다. 아카이브 파일은 CERT.SF 및 CERT.RSA 라는 2개의 추가 파일들을 포함한다. CERT.SF는 모든 다른 아카이브 파일들의 암호화 해시를 포함하고; CERT.RSA 는 서명 검증에 사용된 공개 키를 포함한다. CERT.SF 만이 RSA 개인 키로 서명된다. CERT.SF에 대한 RSA 서명은 설치 중에 APK 파일의 전체 내용의 검증을 가능하게 한다. 사실, CERT.SF 파일에 언급된 모든 파일들은 CERT.SF 가 해시를 포함하기 때문에 간접적으로 서명된다. 설치 전에 임의의 파일을 변경하면 소프트웨어는 파일 다이제스트 (file digest) 가 CERT.SF 파일에 있는 해시와 매칭하지 않음을 검출하기 때문에 오류가 발생한다. 다르게는, (이미 설명한 체크섬 기반 검증에 대한 공격과 마찬가지로) CERT.SF 파일 내부 암호화 해시 값을 수정하는 것은 서명 검증 중에 오류에 이른다.
DEX 파일 헤더는 DEX 파일의 컨텐츠에 대한 글로벌 체크섬 (global checksum) 도 포함한다. 애플리케이션의 첫번째 실행에서, 안드로이드 시스템은, DEX로 해석된 바이트 코드를 ODEX (Optimized DEX) 라고 불리는 최적화된 머신 명령 시퀀스로 실행 전 바로 적시에 (just in time before) 수정하는 최적화기 (optimizer) 를 사용한다. 최적화기는 또한 체크섬을 업데이트한다. 다음으로, ODEX 파일은 향후 사용을 위하여 안드로이드 파일 시스템 내의 특정 저장소에 저장된다. ODEX 파일은 애플리케이션 소프트웨어에 대한 레퍼런스 (reference) 가 되며, 그것이 존재하면, 원래 DEX 파일은 더 이상 사용되지 않는다.
런타임 시에, 시스템은 ODEX 체크섬을 사용하여 애플리케이션의 무결성을 검증할 수도 있다. 그러나 이 옵션은 안드로이드 운영 시스템에서 기본적으로 설정되지 않고, ODEX 코드를 실행하는데 사용되는 Dalvik 머신은, 체크섬 검증이 실행 성능 및 부트 시간에 무시할 수 없는 영향을 주기 때문에, 항상 ODEX 체크섬을 확인하는 것은 아니다.
안드로이드 버전 5.0 이상은 Dalvik 머신을 대체하는 안드로이드 런타임 (ART) 을 도입했다. 그 애플리케이션은 여전히 DEX 코드에서 사용되지만, 설치시 DEX 코드는 AOT (ahead-of-time compilation) 피처를 사용하여 네이티브 코드로 컴파일된다. 이전 솔루션과 유사하게, DEX 파일 상의 AOT 컴파일은 (이전 솔루션에서 ODEX 을 대신하는) 바이너리 실행가능 링크가능 형식 (ELF) 파일을 생성한다. 다음으로, 애플리케이션의 DEX 코드가 한번 컴파일된 다음, 그 후에 애플리케이션이 실행될 때마다 ELF 코드가 개시된다. ART 는 네이티브 코드를 직접 실행하므로 (ELF 코드), 애플리케이션의 실행을 더 빠르게 하고 전반적인 전력 소비를 향상시킨다.
따라서 안드로이드 시스템에서, APK 서명은 설치시에만 검증됨을 알 수 있다. 또한 APK는, 중앙 관리자 (central authority) 에 의해 서명되지 않은 경우에도, 사용자가 비신뢰 소스에서 오는 애플리케이션의 설치를 허용하면 안드로이드 디바이스에 설치될 수 있다. 다음으로 애플리케이션 개발자는 임의의 신뢰 관리자 (trusted authority) 에 링크되지 않은 자신의 자체 서명된 인증서를 사용한다. 그 경우 변조된 애플리케이션은 그의 소유자가 모르는 사이에 안드로이드 디바이스 상에 임의의 해커에 의해 재서명되거나 또는 재설치될 수 있다.
이미 언급했듯이, 안드로이드 애플리케이션은 인터프리터 포터블 형식 (DEX) 을 사용한다. 이 포터블 형식은 ARM, x86, MIPS, Little/Big Endian 등 상이한 아키텍처와 특성으로 큰 세트의 디바이스들 상에 실행할 수 있다. 성능을 향상시키기 위해, DEX 코드는 타겟 디바이스를 위해 최적화된 ODEX 또는 ELF 바이너리를 생성하기 위해 애플리케이션의 설치 시 또는 처음 사용시에 수정된다. 최적화 또는 OAT 컴파일 동안, 코드에서 여러 가지 사항들을 수정할 수 있다; 명령들이 다른 것들에 의해 대체되거나, 명령들의 정렬을 변경할 수도 있거나, 바이트 순서를 바꿀 수 있는 등이다.
그 최적화 및 OAT 컴파일은 보안 문제를 제기한다. DEX 파일의 서명은 CERT.SF 및 CERT.RSA를 사용하여 여전히 검증될 수 있지만, 이것은 ODEX 및 ELF 파일에 대해서는 그러하지 않은데, 그것들이 수정되었고 그들의 무결성이 원래 DEX 서명에 더 이상 링크되지 않기 때문이다. 즉, 무결성과 신뢰성은 설치시에만 검증될 수 있지만, 공격자가 ODEX 및 ELF 코드를 수정하고 이에 따라 헤더에서 체크섬을 업데이트할 수 있으므로 런타임시에는 그렇지 않다.
따라서 시스템은 원격 공격과 루트 공격이라는 적어도 2가지 종류의 공격에 취약하다. 원격 공격에서, 다운로드된 악의적인 애플리케이션은 권한 (privilege) 을 상승시키고 시스템 허가 (system permission) 를 얻는다. 다음으로, 악의적인 애플리케이션은 내부 스토리지의 캐시 저장소에 저장된 ODEX 및 ELF 파일을 변조할 수도 있다. 루트 공격에서, 공격자는, 예를 들어, 디바이스 세션을 잠그지 않고 소유자가 부재 중일 때 디바이스에 액세스하여 또는 디바이스를 절취 (purloining) 하여 안드로이드 디바이스를 획득한다. 공격자는 USB 링크를 통해 디바이스의 내부 스토리지로부터 설치된 애플리케이션을 취출하고, 애플리케이션을 수정하고, 다음으로 수정된 애플리케이션을 다시 내부 스토리지로 푸시할 수 있다. 후자의 공격이 성공하기 위해, 디바이스는 "루팅" 되어야 한다 (즉, 디바이스의 안드로이드 시스템을 제어하기 위해 "루트 액세스"가 필요하다).
따라서 안드로이드 애플리케이션 무결성에서의 신뢰는 애플리케이션의 라이프 사이클 동안 깨질 수 있다. 안드로이드 시스템 상에 설치된 것을 신뢰할 수는 있지만 실행중인 것을 반드시 신뢰할 수 있는 것은 아니다.
해석된 코드 애플리케이션의 무결성 및 진정성과 관련된 문제점들 중의 적어도 일부를 극복하는 솔루션을 갖는 것이 바람직하다는 것이 이해될 것이다. 본 개시는 그러한 솔루션을 제공한다.
개시의 요약
제 1 양태에서, 본 개시는 애플리케이션을 처리하기 위한 디바이스에 관한 것이다. 이 디바이스는 애플리케이션을 수신하도록 구성된 인터페이스, 애플리케이션 및 서명된 체크섬을 저장하도록 구성된 메모리, 및 수정된 애플리케이션을 획득하기 위해 애플리케이션을 수정하고, 수정된 애플리케이션에 대해 생성된 체크섬을 신뢰 엔티티로 전송하고, 신뢰 엔티티로부터 전송된 체크섬에 대응하는 서명된 체크섬을 수신하고, 서명된 체크섬을 상기 메모리에 저장하도록 구성된 처리 유닛을 포함한다.
제 1 양태의 다양한 실시형태들은 이하를 포함한다:
애플리케이션이 제 1 체크섬과 함께 수신되는 것, 및 처리 유닛이 또한 제 1 체크섬을 사용하여 애플리케이션의 무결성을 검증하도록 구성되는 것.
처리 유닛이 서명된 체크섬을 사용하여 수정된 애플리케이션의 런타임시에 수정된 애플리케이션의 무결성을 검증하도록 구성되는 것.
애플리케이션이 해석된 코드 (DEX) 로서 구현되고 수정된 애플리케이션이 최적화된 해석된 코드 (ODEX) 로서 구현되거나 또는 수정된 애플리케이션이 네이티브 코드 (ELF) 로서 컴파일되는 것. 처리 유닛은 해석된 코드에 대한 체크섬을 해석된 코드 또는 최적화된 해석된 코드에 대한 헤더 내의 서명된 체크섬으로 대체하도록 구성되는 것이 유리하다.
디바이스가 스마트 폰 또는 태블릿인 것.
신뢰 엔티티가 디바이스에서 구현되는 것. 신뢰 엔티티는 애플리케이션에 대한 적어도 하나의 체크섬을 저장하고, 수정된 애플리케이션에 대한 체크섬이 애플리케이션에 대한 저장된 체크섬과 매칭하는 지를 검증하고, 그리고 서명용 키를 사용하여 수정된 애플리케이션에 대한 체크섬에 서명하도록 구성되는 것이 유리하다. 서명용 키는 소프트웨어 보호 기술을 사용하여 보호되는 것이 바람직하다.
신뢰 엔티티는 별도의 디바이스인 것 및 인터페이스는 또한 처리 유닛으로부터 수정된 애플리케이션에 대한 체크섬을 수신하고 수정된 애플리케이션에 대한 체크섬을 신뢰 엔티티에 전송하고, 신뢰된 엔티티로부터 서명된 체크섬을 수신하고 서명된 체크섬을 처리 유닛에 전송하도록 구성되는 것.
처리 유닛이 수정된 애플리케이션에 대한 체크섬과 함께 애플리케이션에 대한 활성화 코드를 전송하도록 구성되는 것.
처리 유닛이 서명 인증서와 함께 서명된 체크섬을 수신하도록 구성되는 것.
제 2 양태에서, 본 개시는 애플리케이션을 처리하는 방법에 관한 것이다. 디바이스는 애플리케이션을 수신하고, 애플리케이션을 수정하여 수정된 애플리케이션을 획득하고, 수정된 애플리케이션에 대해 생성된 체크섬을 신뢰 엔티티로 전송하고, 신뢰 엔티티로부터 전송된 체크섬에 대응하는 서명된 체크섬을 수신하고, 서명된 체크섬을 메모리에 저장한다.
이제, 본 개시의 바람직한 피처들은 첨부 도면들을 참조하여, 비한정적인 예에 의해, 설명될 것이며, 여기서: 도 1은 본 개시가 구현되는 예시적인 시스템을 도시하고; 그리고
도 2는 본 개시의 바람직한 실시 형태에 따른 방법의 바람직한 실시형태를 도시한다.
실시형태들의 설명
도 1은 본 개시가 구현되는 예시적인 시스템을 도시한다. 시스템은 디바이스 (110), 애플리케이션 제공자 (애플리케이션 저장부) (120) 및 신뢰 엔티티 (130) 를 포함한다. 디바이스 (110) 는 스마트 폰 또는 태블릿과 같은 안드로이드 OS를 실행하는 임의의 종류의 적합한 디바이스일 수 있고, 적어도 하나의 하드웨어 처리 유닛 ("프로세서") (111), 메모리 (112), 사용자와 상호작용하기 위한 사용자 인터페이스 (113), 및 인터넷과 같은 접속 (140) 을 통해 애플리케이션 제공자 (120) 및 신뢰 엔티티 (130) 와 통신하기 위한 통신 인터페이스 (114) 를 포함한다. 당업자는 도시된 디바이스가 명료성의 이유로 매우 단순화되어 있다는 것 및 실제 디바이스는 추가적으로 전원 공급부 및 영구 스토리지와 같은 피처들을 포함한다는 것을 알 것이다.
애플리케이션 제공자 (120) 는 디바이스 (110) 에 의해 다운로드될 수 있는 적어도 하나의 애플리케이션 APK 파일 (122) 을 저장한다. 애플리케이션 제공자 (120) 는 또한 애플리케이션 DEX 파일에 대응하는 상이한 ODEX 또는 ELF 파일에 대한 체크섬을 생성하도록 구성된 하드웨어 프로세서 (124) 를 포함한다. 이 체크섬은 DEX 파일을 상이한 테스트 또는 레퍼런스 디바이스 상에 설치하고 결과적인 ODEX 또는 ELF 파일들로부터 체크섬을 계산하여 생성될 수 있다. 애플리케이션 제공자 (120) 는 또한, 애플리케이션 DEX 파일에 대응하는 상이한 ODEX 또는 ELF 파일들에 대한 체크섬을 신뢰 엔티티 (130) 에 전송하도록 구성된다.
신뢰 엔티티 (130) 는 안드로이드 OS 내부에서 또는 독립된 디바이스 상에서 구현될 수 있다. 신뢰 엔티티 (130) 는 애플리케이션에 대한 ODEX 또는 ELF 체크섬을 저장하기 위한 메모리, 디바이스 (110) 상의 안드로이드 OS 로부터 ODEX 또는 ELF 체크섬을 수신하기 위한 인터페이스, 애플리케이션에 대해 수신된 ODEX 또는 ELF 체크섬이 애플리케이션에 대한 저장된 ODEX 또는 ELF 체크섬에 매칭하는지를 검증하기 위한 처리 유닛, ODEX 또는 ELF 체크섬에 서명하는데 사용될 개인 서명용 키 (132) 및 서명된 ODEX 또는 ELF 체크섬을 디바이스 (110) 에 전송하기 위한 인터페이스를 포함한다. 신뢰 엔티티 (130) 가 안드로이드 OS 내부에서 구현되는 경우, 개인 서명용 키는 바람직하게는 소프트웨어 보호 기술, 이를테면 코드 난독화 (code obfuscation) 및 화이트 박스 암호 (white-box cryptography) 를 사용하여, 또는 키 저장부 또는 암호 엔진 (crypto engine) 과 같은 특정 하드웨어의 사용을 통해, 보호된다.
도 2는 바람직한 실시 형태에 따른 방법의 플로우차트를 도시한다. 단계 (S202) 에서, 애플리케이션 제공자 (120) 는 안드로이드 디바이스들에 제공하는 애플리케이션에 대한 다수의 ODEX 또는 ELF 체크섬을 신뢰 엔티티 (130) 에 전송한다. 단계 (S204) 에서, 디바이스 (110)는 애플리케이션에 대한 APK 파일을 다운로드하여 설치한다. 이미 언급한 바와 같이, 설치 동안, 디바이스 (110) 는 APK 파일에서 DEX 를 최적화 또는 OAT 컴파일하고, ODEX 또는 ELF를 획득하고, DEX 헤더에 ODEX 또는 ELF 코드에 대한 체크섬을 추가한다. CERT.SF 파일의 해시는 디바이스 (110) 가 DEX의 무결성을 검증할 수 있게 한다는 것에 유의해야 한다.
애플리케이션이 처음 실행될 때, 소스 획득 모듈은 ODEX 또는 ELF 파일의 컨텐츠를 메모리 (112) 내로 판독하고, DEX 헤더로부터 ODEX 또는 ELF 체크섬 (CS) 을 판독하여, 그것을, 단계 (S206) 에서, 신뢰 엔티티 (130) 에 송신한다. ODEX 또는 ELF 체크섬은 바람직하게는 보안 인증 채널과 같은 보호 접속을 통해 전송된다. 소스 획득 모듈은 애플리케이션의 네이티브 라이브러리에 포함되어 있다 (안드로이드 애플리케이션의 일부는 C/C++ 언어와 같은 Java 이외의 코드를 사용하여 개발될 수 있다). JNI (Java Native Interface) 는 Dalvik 머신에서 실행되는 JAVA 코드가 애플리케이션과 함께 전달되는 네이티브 라이브러리를 호출 할 수 있게 한다.
애플리케이션이 입력될 활성화 코드를 요구하는 경우, 체크섬은 활성화 코드와 함께 원격 신뢰 엔티티 (130) 로 전송될 수 있다.
신뢰 엔티티 (130) 는 바람직하게는 단계 (S208) 에서, 수신된 ODEX 또는 ELF 체크섬이 애플리케이션에 대한 저장된 ODEX 또는 ELF 체크섬 중 하나에 대응하는지 체크한다. 이것이 그 경우이면, 단계 (S210) 에서, 신뢰 엔티티 (130) 는 수신 된 ODEX 또는 ELF 체크섬에 개인 서명용 키를 사용하여 서명하고, 단계 (S212) 에서 서명된 ODEX 또는 ELF 체크섬을 디바이스 (110) 에 반환한다. 또한, 신뢰 엔티티 (130) 는 서명된 ODEX 또는 ELF 체크섬과 함께 대응하는 공개 키를 포함하는 서명 인증서를 전송할 수 있다.
단계 (S214) 에서, 소스 획득 모듈은 서명된 ODEX 또는 ELF 체크섬 (및 이용가능하고 필요하다면, 서명용 인증서) 을 수신하여 저장한다.
다음으로, 개인 서명용 키에 대응하는 공개 키에 액세스하는 애플리케이션 또는 안드로이드 OS는, ODEX 또는 ELF에 대한 체크섬을 계산하고 그것을 서명된 ODEX 또는 ELF 체크섬과 비교하는 것에 의해, 단계 (S216) 에서 ODEX 또는 ELF의 무결성을 체크할 수 있다. 서명용 인증서의 무결성은 또한, 디바이스 상에 설치된 신뢰 루트 인증서의 사용을 통해 또는 궁극적으로 신뢰 루트 인증서에 이르는 인증서 체인의 사용을 통하여 검증될 수 있다.
애플리케이션의 후속 실행시 또는 애플리케이션의 현재 실행 동안의 임의의 시점에서, 애플리케이션의 무결성은 단계 (S216) 에서와 동일한 방식으로, 즉 ODEX 또는 ELF에 대한 체크섬을 계산하고 이를 서명된 ODEX 또는 ELF 체크섬과 비교하여, 검증될 수도 있다. 이를 위해, ODEX 또는 ELF의 무결성을 체크하는 옵션은 안드로이드 운영 시스템에서 설정되는 것이 유리하다.
런타임 무결성 검증에 필요한 코드는 기존 안드로이드 OS의 일부이거나 또는 애플리케이션에 대해 전달되는 APK 패키지의 일부이기 때문에 그 솔루션은 현재 사용된 안드로이드 시스템과 호환된다는 것에 유의한다.
본 설명에서, '체크섬'이라는 용어는 그것이 생성된 데이터가 체크섬의 생성 후에 수정되었는지 여부의 검증을 가능하게 하는 값을 커버하도록 의도된다. 따라서, 체크섬은 예를 들어 해시 값, CRC (Cyclic Redundancy Check) 값 또는 다른 종류의 다이제스트일 수도 있다; 체크섬으로부터 코드를 획득하는 것이 계산상으로 불가능한 것이 바람직하다. 또한, 명료성을 위해 단일 체크섬이 사용되었지만, 복수의 체크섬이 사용될 수도 있고, 여기서 체크섬은 코드의 구별되는 부분에 대해 생성될 수도 있고 (상이한 부분들이 오버랩될 수도 있음), 코드의 상이한 부분들에 대한 복수의 체크섬들이 비교에 사용되는 단일 글로벌 체크섬을 생성하는 데 사용된다. 서명은 HMAC (Hash-based Message Authentication Code) 또는 예를 들어 RSA, DSA (Digital Signature Algorithm) 또는 ECDSA (Elliptic Curve Digital Signature Algorithm) 에 기반한 서명과 같은 임의의 적합한 암호화 서명일 수도 있다.
본 솔루션은 원격 공격을 성공적으로 저지할 수 있음을 알 수 있다.
신뢰 엔티티가 수신된 ODEX 또는 ELF 체크섬이 '합법적인' (legitimate) 코드에 대응하는지를 체크하는 경우 루트 공격도 저지될 수 있다. 이는 수신된 ODEX 체크섬이 수정 코드를 포함하는 APK의 체크섬이 아닌지 (공격자가 애플리케이션 공급자로부터의 다운로드 후 코드를 수정하는 경우일 수도 있음) 를 검증하는 것이다. 이러한 이유로 애플리케이션 제공자 (120) 가 가능한 ODEX 또는 ELF 체크섬을 신뢰 엔티티 (130) 로 전송하는 것이 바람직하며; 변형 예에서, 신뢰 엔티티 (130) 가 주어진 타겟 디바이스에 대해 애플리케이션의 DEX 코드를 OAT 컴파일 또는 최적화함으로써 상이한 ODEX 또는 ELF 체크섬을 생성한다. 잠재적 체크섬의 수는 제한된 세트의 디바이스 하드웨어 파라미터 (CPU 엔디언, CPU 대칭 다중처리 (SMP) 모드 등) 에 의존하므로 파라미터 조합의 수는 제한된다는 것에 유의한다. 예를 들어 Nexus 7 과 삼성 Galaxy 탭 P5100 간의 DEX 최적화에 대해서는 SMP 모드만 상이하다.
본 솔루션은 안드로이드 환경에서 설명되었지만, 런타임시 설치된 응용 프로그램의 보안 무결성 검증을 가능하게 하지 않고서 설치 중에 코드를 수정하는 다른 운영 시스템에 적응될 수 있다.
따라서, 본 개시는 안드로이드 디바이스에서 애플리케이션들의 런타임 무결성을 가능하게 할 수 있는 솔루션을 제공한다는 것이 이해될 것이다.
설명 및 (적절한 경우) 청구 범위 및 도면에 개시된 각각의 피처는 독립적으로 또는 임의의 적절한 조합으로 제공될 수도 있다. 하드웨어로 구현되는 것으로 설명된 피처들은 또한 소프트웨어로 구현될 수도 있으며, 그 역 또한 마찬가지이다. 특허 청구 범위에 나타나는 참조 부호는 단지 예시를 위한 것이며 청구 범위의 범위를 제한하는 효과를 갖지 않는다.

Claims (13)

  1. 애플리케이션을 처리하기 위한 디바이스 (110) 로서,
    상기 애플리케이션을 수신하도록 구성된 인터페이스 (114);
    상기 애플리케이션 및 서명된 체크섬을 저장하도록 구성된 메모리 (112); 및
    처리 유닛 (111) 을 포함하고,
    상기 처리 유닛 (111) 은
    - 상기 애플리케이션을 수정하여 수정된 애플리케이션을 획득하고;
    - 상기 수정된 애플리케이션에 대해 생성된 체크섬을 신뢰 엔티티에 전송하고;
    - 전송된 상기 체크섬에 대응하는 서명된 체크섬을 상기 신뢰 엔티티로부터 수신하고; 그리고
    - 상기 서명된 체크섬을 상기 메모리 (112) 에 저장하도록 구성되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  2. 제 1 항에 있어서,
    상기 애플리케이션은 제 1 체크섬과 함께 수신되고, 및 상기 처리 유닛은 또한 상기 애플리케이션의 무결성을 검증하기 위해 상기 제 1 체크섬을 사용하도록 구성되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  3. 제 1 항에 있어서,
    상기 처리 유닛은 또한, 상기 서명된 체크섬을 사용하여 상기 수정된 애플리케이션의 런타임시에 상기 수정된 애플리케이션의 무결성을 검증하도록 구성되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  4. 제 1 항에 있어서,
    상기 애플리케이션은 해석된 코드로서 구현되고 상기 수정된 애플리케이션은 최적화된 해석된 코드로서 또는 네이티브 코드로서 구현되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  5. 제 4 항에 있어서,
    상기 처리 유닛은 상기 해석된 코드에 대한 체크섬을 상기 해석된 코드 또는 상기 최적화된 해석된 코드에 대한 헤더 내의 상기 서명된 체크섬으로 대체하도록 구성되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  6. 제 1 항에 있어서,
    상기 디바이스는 스마트 폰 또는 태블릿인, 애플리케이션을 처리하기 위한 디바이스 (110).
  7. 제 1 항에 있어서,
    상기 신뢰 엔티티는 상기 디바이스에서 구현되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  8. 제 7 항에 있어서,
    상기 신뢰 엔티티는 상기 애플리케이션에 대한 적어도 하나의 체크섬을 저장하고, 상기 수정된 애플리케이션에 대한 상기 체크섬이 상기 애플리케이션에 대한 저장된 체크섬과 매칭하는 지를 검증하고, 그리고 서명용 키 (132) 를 사용하여 상기 수정된 애플리케이션에 대한 상기 체크섬에 서명하도록 구성되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  9. 제 8 항에 있어서,
    상기 서명용 키는 소프트웨어 보호 기술을 사용하여 보호되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  10. 제 1 항에 있어서,
    상기 신뢰 엔티티는 별도의 디바이스이고 상기 인터페이스 (114) 는 또한 상기 처리 유닛으로부터 상기 수정된 애플리케이션에 대한 상기 체크섬을 수신하고 상기 수정된 애플리케이션에 대한 상기 체크섬을 상기 신뢰 엔티티에 전송하고, 상기 신뢰 엔티티로부터 상기 서명된 체크섬을 수신하고 상기 서명된 체크섬을 상기 처리 유닛에 전송하도록 구성되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  11. 제 1 항에 있어서,
    상기 처리 유닛은 또한, 상기 수정된 애플리케이션에 대한 상기 체크섬과 함께 상기 애플리케이션에 대한 활성화 코드를 전송하도록 구성되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  12. 제 1 항에 있어서,
    상기 처리 유닛은 서명 인증서와 함께 상기 서명된 체크섬을 수신하도록 구성되는, 애플리케이션을 처리하기 위한 디바이스 (110).
  13. 애플리케이션을 처리하는 방법으로서, 디바이스 (110) 에서
    - 상기 애플리케이션을 수신하는 단계 (S204);
    - 상기 애플리케이션을 수정하여 수정된 애플리케이션을 획득하는 단계 (S206);
    며상기 수정된 애플리케이션에 대해 생성된 체크섬을 신뢰 엔티티에 전송하는 단계 (S206);
    - 전송된 상기 체크섬에 대응하는 서명된 체크섬을 상기 신뢰 엔티티로부터 수신하는 단계 (S212); 및
    - 상기 서명된 체크섬을 메모리 (112) 에 저장하는 단계 (S214)
    를 포함하는, 애플리케이션을 처리하는 방법.
KR1020177014266A 2014-11-28 2015-11-26 애플리케이션 무결성 검증을 제공하기 위한 방법 및 디바이스 KR20170088858A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP14306918.5 2014-11-28
EP14306918.5A EP3026557A1 (en) 2014-11-28 2014-11-28 Method and device for providing verifying application integrity
PCT/EP2015/077832 WO2016083537A1 (en) 2014-11-28 2015-11-26 Method and device for providing verifying application integrity

Publications (1)

Publication Number Publication Date
KR20170088858A true KR20170088858A (ko) 2017-08-02

Family

ID=52023429

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177014266A KR20170088858A (ko) 2014-11-28 2015-11-26 애플리케이션 무결성 검증을 제공하기 위한 방법 및 디바이스

Country Status (6)

Country Link
US (1) US20170270319A1 (ko)
EP (2) EP3026557A1 (ko)
JP (1) JP2018503157A (ko)
KR (1) KR20170088858A (ko)
CN (1) CN107003916A (ko)
WO (1) WO2016083537A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101883997B1 (ko) 2017-11-29 2018-08-02 주식회사 스틸리언 의존 관계형 위변조 무결성 체크를 이용한 암호화 처리장치 및 방법
KR20200063535A (ko) * 2018-11-28 2020-06-05 삼성전자주식회사 서버 및 이를 이용한 어플리케이션의 무결성 판단 방법
KR20210062360A (ko) * 2019-11-21 2021-05-31 성균관대학교산학협력단 안드로이드 기반에서 캐시 변조 방지 방법 및 시스템
KR20210131989A (ko) * 2020-04-23 2021-11-03 구글 엘엘씨 프라이버시 보호 애플리케이션 및 장치 오류 검출

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101832594B1 (ko) * 2016-02-18 2018-02-26 라인 가부시키가이샤 중간 언어 파일의 로딩 속도 개선을 위한 방법 및 시스템
CN106066686B (zh) 2016-05-31 2019-02-05 Oppo广东移动通信有限公司 一种信息处理方法及终端设备
CN106250180B (zh) * 2016-07-27 2019-10-11 宇龙计算机通信科技(深圳)有限公司 一种odex优化控制方法及移动终端
US10642971B2 (en) * 2017-09-04 2020-05-05 Cisco Technology, Inc. Methods and systems for ensuring program code flow integrity
KR101875866B1 (ko) * 2017-11-06 2018-07-06 주식회사 엠시큐어 모바일 어플리케이션의 취약점 점검 방법 및 서버
CN113645230B (zh) * 2018-06-06 2023-04-28 北京八分量信息科技有限公司 一种节点的可信值分析系统及方法
CN109495271A (zh) * 2018-10-19 2019-03-19 北京梆梆安全科技有限公司 比较apk文件方法、装置、服务器及其存储介质
DE102018129354A1 (de) * 2018-11-21 2020-05-28 Phoenix Contact Gmbh & Co. Kg Verfahren zum Bearbeiten von Anwendungsprogrammen auf einem verteilten Automatisierungssystem
CN116132162A (zh) 2019-03-27 2023-05-16 创新先进技术有限公司 使用高可用性的可信执行环境检索区块链网络的公共数据
CN115967534A (zh) 2019-03-27 2023-04-14 创新先进技术有限公司 使用可信执行环境检索区块链网络的公开数据
WO2019120325A2 (en) 2019-03-29 2019-06-27 Alibaba Group Holding Limited Retrieving access data for blockchain networks using highly available trusted execution environments
FR3103073B1 (fr) * 2019-11-12 2021-12-03 Thales Sa Serveur multimedia destine a etre embarque a bord d'un aeronef, systeme electronique de divertissement comprenant un tel serveur, procede de configuration logicielle d'un tel serveur et programme d'ordinateur associe
CN111090889A (zh) * 2019-12-05 2020-05-01 深圳和而泰家居在线网络科技有限公司 一种检测elf文件的方法及电子设备
CN111090865B (zh) * 2019-12-17 2022-01-25 支付宝(杭州)信息技术有限公司 一种密钥授权方法和系统
CN112306512B (zh) * 2020-11-09 2023-12-26 武汉天喻信息产业股份有限公司 一种基于ccid协议下载安装apk文件的方法及系统
CN117992969A (zh) * 2024-04-03 2024-05-07 哈尔滨工业大学(深圳)(哈尔滨工业大学深圳科技创新研究院) 一种可信的系统完整性校验方法和装置、电子设备

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7526811B1 (en) * 2001-05-22 2009-04-28 Novell, Inc. Methods for detecting executable code which has been altered
FR2849230B1 (fr) * 2002-12-24 2005-04-22 Francois Bangui Procede et dispositif de verification de l'integrite d'une application logicielle sans cle de chiffrement/dechiffrement
EP1533695B1 (en) * 2003-11-19 2013-08-07 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Updating data in a mobile terminal
JP2006025211A (ja) * 2004-07-08 2006-01-26 Nippon Telegraph & Telephone West Corp ピアツーピア端末装置並びにピアツーピア通信システム、ピアツーピア通信方法、ピアツーピア端末プログラム
US9177153B1 (en) * 2005-10-07 2015-11-03 Carnegie Mellon University Verifying integrity and guaranteeing execution of code on untrusted computer platform
US20070150966A1 (en) * 2005-12-22 2007-06-28 Kirschner Wesley A Method and apparatus for maintaining a secure software boundary
JP2009211187A (ja) * 2008-02-29 2009-09-17 Hitachi Ltd 情報処理装置
CN101610150B (zh) * 2009-07-22 2015-08-12 中兴通讯股份有限公司 第三方数字签名方法和数据传输系统
EP2362314A1 (en) * 2010-02-18 2011-08-31 Thomson Licensing Method and apparatus for verifying the integrity of software code during execution and apparatus for generating such software code
JP2012048445A (ja) * 2010-08-26 2012-03-08 Fuji Electric Co Ltd プログラム実行装置、プログラム生成装置、プログラム正否判定方法、および、プログラム加工方法
ES2902644T3 (es) * 2011-02-11 2022-03-29 Siemens Healthcare Diagnostics Inc Sistema y método para actualización segura de software
JP2012212292A (ja) * 2011-03-31 2012-11-01 Dainippon Printing Co Ltd シンクライアントシステム、シンクライアントｏｓの検証方法
CN102833296B (zh) * 2011-06-13 2018-10-23 伊姆西公司 用于构建安全的计算环境的方法和设备
KR101299099B1 (ko) * 2011-09-07 2013-09-16 주식회사 팬택 임베디드 시스템에서 최적화된 가상화 모듈을 관리하는 장치 및 방법
JP5126447B1 (ja) * 2012-08-31 2013-01-23 大日本印刷株式会社 アプリケーションプログラムの実行方法
JP6261933B2 (ja) * 2012-10-16 2018-01-17 日本放送協会 放送通信連携受信装置及び放送通信連携システム

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101883997B1 (ko) 2017-11-29 2018-08-02 주식회사 스틸리언 의존 관계형 위변조 무결성 체크를 이용한 암호화 처리장치 및 방법
KR20200063535A (ko) * 2018-11-28 2020-06-05 삼성전자주식회사 서버 및 이를 이용한 어플리케이션의 무결성 판단 방법
KR20210062360A (ko) * 2019-11-21 2021-05-31 성균관대학교산학협력단 안드로이드 기반에서 캐시 변조 방지 방법 및 시스템
KR20210131989A (ko) * 2020-04-23 2021-11-03 구글 엘엘씨 프라이버시 보호 애플리케이션 및 장치 오류 검출
KR20230023826A (ko) * 2020-04-23 2023-02-17 구글 엘엘씨 프라이버시 보호 애플리케이션 및 장치 오류 검출
US11928237B2 (en) 2020-04-23 2024-03-12 Google Llc Privacy preserving application and device error detection

Also Published As

Publication number Publication date
JP2018503157A (ja) 2018-02-01
US20170270319A1 (en) 2017-09-21
WO2016083537A1 (en) 2016-06-02
CN107003916A (zh) 2017-08-01
EP3224719A1 (en) 2017-10-04
EP3026557A1 (en) 2016-06-01

Similar Documents

Publication Publication Date Title
KR20170088858A (ko) 애플리케이션 무결성 검증을 제공하기 위한 방법 및 디바이스
US20170262656A1 (en) Method and device for providing verifying application integrity
US20170262657A1 (en) Method and device for providing verifying application integrity
Buhren et al. Insecure until proven updated: analyzing AMD SEV's remote attestation
US20170262658A1 (en) Method and device for providing verifying application integrity
KR101471589B1 (ko) 공통중간언어 기반 프로그램을 위한 보안 제공 방법
US7577848B2 (en) Systems and methods for validating executable file integrity using partial image hashes
CN112507328B (zh) 一种文件签名方法、计算设备及存储介质
US20170024230A1 (en) Method, apparatus, and computer-readable medium for ofuscating execution of an application on a virtual machine
Piao et al. Server‐based code obfuscation scheme for APK tamper detection
Falsina et al. Grab'n run: Secure and practical dynamic code loading for android applications
US11496317B2 (en) Software validation for untrusted computing systems
CN112511306A (zh) 一种基于混合信任模型的安全运行环境构建方法
KR20130053179A (ko) 단말기의 어플리케이션 실행 시스템 및 방법
CN112115430A (zh) 一种apk的加固方法、电子设备及存储介质
Titze et al. Preventing library spoofing on android
CN107689934B (zh) 一种保障信息安全的方法、服务器及客户端
RU2812867C1 (ru) Защита двоичных файлов типовых коммерческих программ от пиратства с использованием аппаратных анклавов
CN112257033A (zh) 一种应用的打包方法、装置及其设备
CN117519813A (zh) 一种文件运行方法及装置

Legal Events

Date Code Title Description
WITB Written withdrawal of application