암호화 섹션

• 루팅된 기기에서는 sharedPref, Room, memory 데이터(heap dump)를 가져올 수 있음
• 루팅 탐지만으로는 불충분함
• 양방향 암호화 시
  • JCE를 사용해 구현 가능
    • kotlin은 라이브러리 없음, JCE을 통해 구현
  • JCA도 사용됨

AES

• 128비트 단위로 암호화

AES/GCM

• 갈루와/카운터 모드

GCM 주요 키워드

• TAG
• IV(Initial Vector)

암호화 고려사항

• Base64
• IV, secretKey를 여러 데이터에서 재사용하면 보안 취약점 발생
  • 유니크할수록 좋음
• 적용하려는 암호화 알고리즘에 취약점있는지 검토

Android 암호화 제공

• Andoird KeyStore
• 유의사항
  • sdk 23부터 제공됨
  • 미만에서는 JCE 사용해서 직접 구현해야함
• 데이터 백업 케이스 유의해야함
  • dataStorage 구현하는경우 앱 삭제되면 keyStore에 있는 키가 날라가면서 재설치 시 데이터를 못불러옴

EncryptedSharedPreferences 절망편

• Tink를 통해 암호화됨 -> Google 오픈소스 암호화 라이브러리
• 몇몇 에러가 있어서 이젠 deprecated됨
• 한정된 암호화 알고리즘 제공
• 크래시 방어로직 추가 혹은 다른 방안 적용

Room 암호화

• 공식적으로 제공해주는건 없음
• 주로 SQLCipher, 서드파티 라이브러리 사용함
• 다만 취약점이 존재하기에 한번 고려는 해봐야함
• Cipher객체를 활용해서 직접 DB 암호화 로직을 구현하는것도 좋은 방안임

  메모리 상에 평문이 노출되는 시점은 존재함 따라서 최대한 메모리상에서 짧게 사용되도록 개발, GC가 빨리 돌수 있도록 + 사용 후 인스턴스 삭제

앱 취약점 진단

• OWASp MASVS
  • 모바일 앱 보안을 위한 표준
• 공식문서 Security | privacy-and-security 하위 문서로도 체크 가능
  • 진단 및 해결방안이 있음

취약점 진단 툴

• drozer -> 동적 분석 툴
• Qodana, sonarQube -> 정적 분석 툴

선언형 UI의 주요 키워드

주요 요소들

• Flex(FlexBox)
  • CSS에서 사용하는 레이아웃 배치 기업 중 하나
  • 미리 알고가면 좀 편함
• MVI, ios에서는 TCA
  • 다만 이런 방식은 좀 오래된 방식임
• SWR
  • stale-while-revalidate
  • 백그라운드에서 데이터 받아오는 동안 캐시된 데이터를 사용할 수 있는 지정된 기간을 의미
• 비동기 상태 관리
  • 기존의 캐시된 데이터를 활용하는 방식
  • 캐시데이터로 UI 그리고 백그라운드에서 새 데이터 불러오는 방식
  • 예시 -> optimistic Update 방식
    • 성공적으로 응답할거라고 UI 미리 변경하고 실패하면 롤백하는 방식
  • react에서는 react query라는 방식을 제공해줌
  • compose에서는 state sealedClass 만들어서 loading, success, fail로 구분해서 UI 그리는 거랑 비슷한 느낌, 다만 캐시데이터를 사용하는 기준을 설정함 -> staleTIme

Server Driven Compose With Firebase

• 지금 우리가 사용하는 방법은 Data-Driven UI임

• 서버에서 domain data, componenet(layout)을 서버에서 내려주는 방식

• 쉽게 말하면 json으로 레이아웃정보를 내려주는거임, 앱에서는 해당 정보를 기반으로 그려주기만함

• 서버는 "무엇을"그릴지를 담당, 앱에서는 말그대로 그려주기만함

• 서버에서 배포만으로 앱에서 디자인이 변경됨, 디자인 시스템이 잘 개발되어있다면 여러 버전에서도 일관된 UI를 제공함

• 간단하게 구현해 보고 싶으면 Firebase Realtime Database를 사용해볼 수 있음

  가장 중요한건 디자인 시스템이 잘 설계되어 있어야함

• 서버 데이터에서 프로퍼티가 쉽게 추가, 삭제될 수 있기에 유연하게 대처할 수 있어야함

  • 이는 직렬화 커스텀이 필요하다고함

디자인 시스템

• UIComponent라는 하나의 인터페이스로 만들어서 사용함

sealed interface UiComponent

모든 Ui는 이런 인터페이스를 상속받아 구현함 -> 이를 통해 컴포넌트 모델링을함
텍스트면 텍스트의 데이터를 데이터클래스로 만들어서 상속받아서 사용함
깃헙참고

Action Handler

• 딥링크, 버튼이벤트 등을 말함
  이 또한 백엔드에서 내려줌
  Handler라는 데이터클래스를 만들어서 해결함

Component Versionng

• 디자인 시스템이 크게 변경된다면?
• 버전마다 다른 UI를 보여줘야한다면?
  상황에 따라 화면별로 or 컴포넌트별로 처리

Fallback

• 잘못된 레이아웃 정보가 내려온다면? -> 아예 아무것도 못그리는 문제가 일어날 수 있음
  직렬화 실패 or 데이터 결함 등 여러이유로 컴포넌트 매칭이 안될경우를 위해 충분한 Fallback처리가 필요함

장점

• 더 빠른 기능 실험
  • 앱심사 업데이트 없이 쉽게 수정 및 배포 가능, 피드백 루프가 빠르며 반복 작업이 신속하게 이루어짐
• 일관된 UI
• 네이티브 성능

단점

• 지연 시간 증가
  • 서버에서 데이터를 받아와야 하기에 기존 방식보단 약간 느릴 수 있음
• 복잡성 및 비용 증가
  • 팀 전체가 레이아웃 데이터 렌더링 방식, 버전관리에 대한 역할 분담과 디자인 시스템 구축이필요
• Fallback 처리
  • 레이아웃 데이터가 잘못된 경우가 반드시 있기에 충분한 Fallback 처리가 요구됨

적합한 경우

• 홈화면
  • 유저가 앱 진입시 가장 먼저 노출되며 자주 변경이 필요한 화면
• 세션 타임이 높은 화면

오픈 소스로 예제가 업로드되어 있음 skydoves 기헙 체크해보기
dove letter를 통해 코틀린, 안드로이드 자료가 올라옴

CMP

KMP는 공식적인 지원이 계속된다면 미래는 굉장히 유망할 것이다
다만 굉장히 많은 지식이 필요함