Tuya SDK를 통해 살펴본 AWS Signed URL 기반 보안 이미지 접근 메커니즘 분석

[pachuho]

클라우드 이미지 접근 시 보안 처리

카메라 기능 중 동작이 인식되면 그 순간을 포착해 이미지로 저장한다. 저장된 이미지는 S3 같은 클라우드에 저장되며 사용자가 원하는 시점에 이미지를 로딩하여 UI에 그린다. Tuya가 제공하는 SDK를 사용하며 손쉽게 구현할 수 있었지만 내부적으로 보안 처리가 어떻게 되어 있는지 제공된 문서가 없다. 가용한 데이터들을 통해 추정한 내용을 정리한다.

개요

"그러면 안될건데요?"

동료 서버 개발자와 클라우드에 저장된 이미지와 영상을 사용자에게 노출 시킬 때 어떤 구조로 데이터를 가져오는지 이야기를 나누었다.

1. Tuya 서버를 거쳐 S3에 저장된 데이터를 가져온다.
2. 직접 S3에 저장된 서버에서 데이터를 가져온다.

우리는 Tuya SDK를 사용하고 있으나 이에 대한 공식 문서나 제대로된 답변을 듣지 못해 로그를 확인해보았다.

https://xxx.s3.ap-northeast-2.amazonaws.com/xxx.jpeg?XXX@aaa

사용자가 접근할 수 있는 카메라 기기를 통해 이미지 정보를 가진 아이템 목록을 가져올 수 있다. 아이템 필드로는 s3 스토리지 저장소로 보이는 url 정보(@ 문자 이후로는 복호화에 사용되는 키라고 한다.)가 존재하며 이를 통해 ImageView에 이미지를 붙이거나 Bitmap으로 가져올 수 있다. 물론 웹상에 url만 가지곤 접근할 수 없도록 암호화된 형태다.

이를 근거로 서버 개발자에게 이미지나 영상은 SDK로부터 전달받은 URL과 복호화 키를 이용해 클라우드에서 직접 가져오는 것 같다고 이야기 했다. 하지만 서버 개발자는 해당 방식만으론 보안상 위험할 것 같다며 정확히 기억 나지 않지만 웹과 백엔드에선 유효기간과 암호화된 url을 통해 데이터에 접근한다며 의견을 냈다. 나는 SDK에서 이미지에 대한 url을 불러오기 위해선 유저 정보가 스마트폰에 캐싱된 상태이므로 내부적으로 복호화에 필요한 메타 데이터를 통해 처리 될 것 같다는 의견을 내며 이야기는 마무리 되었다.

분석

그럼 복호화에 필요한 메타 데이터는 무엇이고 어떻게 처리되는 것일까?
공식 문서나 내부 로직에 대한 답변을 받을 수 없었지만 라이브러리의 일부 코드가 난독화 되어 있지 않아 어느정도 추정을 할 수 있었다. 가장 먼저 Signed URL을 살펴보자.

https://xxx.s3.ap-northeast-2.amazonaws.com/exxx-tuya20602b52adf3cee5/detect/1744253619.jpeg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20250411T144039Z&X-Amz-SignedHeaders=host&X-Amz-Expires=3600&X-Amz-Credential=AKIA4MTWMRQDMDVZXXXX%2F20250410%2Fap-northeast-2%2Fs3%2Faws4_request&X-Amz-Signature=4a612c4bf9eb4ccd512d95630381a329d8fbf9f33b9d0ee9ca7354cd2394xxxx@3a0bb89cf7bexxxx

개인정보로 보이는 데이터들은 xxx로 축약 시켰다.

Tuya 공식문서에서 다음 함수로 이미지를 불러올 수 있다고 가이드 한다.

In an alert, the value of the URL for the attached image consists of the image URL and encryption key, which are concatenated in the format of {path}@{key}. To display the encrypted image, this concatenated string is parsed to get the decryption data.
If the string is not suffixed with @{key}, the attached image is not encrypted.

val img: SimpleDraweeView = findViewById(R.id.img);
if (mUriString.contains("@")) {
    val index = mUriString.lastIndexOf("@")
    try {
        val decryption = mUriString.substring(index + 1)
        val imageUrl = mUriString.substring(0, index)
        val builder = ImageRequestBuilder.newBuilderWithSource(Uri.parse(imageUrl))
                .setRotationOptions(RotationOptions.autoRotateAtRenderTime())
                .disableDiskCache()
        val imageRequest = DecryptImageRequest(builder, "AES", "AES/CBC/PKCS5Padding",
                decryption.toByteArray())
        controller = Fresco.newDraweeControllerBuilder().setImageRequest(imageRequest)
                .build()
    } catch (e: Exception) {
        e.printStackTrace()
    }
} else {
    try {
        uri = Uri.parse(mUriString)
    } catch (e: Exception) {
        e.printStackTrace()
    }
    val builder = Fresco.newDraweeControllerBuilder().setUri(uri)
    controller = builder.build()
}
img.controller = controller

코드를 간단히 살펴보면 @ 문자를 기준으로 전자는 이미지 URL, 후자는 복호화 키로 사용하며
SDK에서 제공하는 함수 setImageURI에 값을 넣으면 이미지가 attach 된다.
AES 암호화 알고리즘을 통해 복호화를 시도하며 처리된 이미지는 Facebook에서 개발한 fresco 라이브러리를 통해 이미지 로딩 이루어 지는 것으로 보인다. 복호화 과정을 알기 위해 DecryptImageRequest 클래스를 살펴보자

[pachuho]

코드 분석

SDK 내부 코드중 대부분의 코드가 난독화가 되어 있어 정확한 데이터 흐름은 파악할 수 없다.
하지만 주요 메소드를 살펴보면서 어떤 보안 과정을 거치는지 유추할 수 있었다.

    public InputStream decryptStream(ResponseBody body) throws IOException, NoSuchPaddingException, NoSuchAlgorithmException, InvalidAlgorithmParameterException, InvalidKeyException {
        byte[] iv = new byte[16];
        EncryptLevel level = EncryptLevel.valueOf(this.decryptHead(body.byteStream(), iv));
        L.d(TAG, "encryptLevel is " + level);
        return DecryptFilter.buildStream(body.byteStream(), level, iv, this.key);
    }

decryptStream함수에서는 IV(초기화 벡터) 16바이트 배열 생성한다.

IV(Initialization Vector)는 대칭키 암호화에서 사용되는 보안 매개변수 중 하나로, 암호화 작업에서 첫 번째 블록(block)을 암호화하기 전에 사용되는 초기화 벡터다. 대칭키 암호화에서 같은 암호화 키를 사용할 경우 같은 평문 메시지를 암호화하면 같은 암호문이 생성되기 때문에 보안성이 저하될 수 있다. 이를 방지하기 위해 초기화 벡터를 사용한다.

생성한 16바이트 배열을 decryptHead로 전달한다.

    private int decryptHead(InputStream inputStream, byte[] ivBuffer) throws IOException {
        byte[] versionBuffer = new byte[4];
        inputStream.read(versionBuffer);
        int version = this.byteArray2Int(versionBuffer);
        int read = inputStream.read(ivBuffer);
        if (read != 16) {
            throw new IOException("iv length error");
        } else {
            inputStream.skip(4L);
            int level;
            if (version == 2) {
                level = inputStream.read();
            } else {
                level = 3;
                inputStream.skip(1L);
            }

            inputStream.skip(39L);
            L.d(TAG, String.format("decryptHead version:%1$s, level:%2$s", version, level));
            return level;
        }
    }

decryptHead 함수에서는 이미지 데이터의 가장 앞부분에서 복호화에 필요한 메타데이터(버전, iv, 암호화 알고리즘 종류 등)를 추출한다.
4바이트 크기의 versionBuffer를 생성하고 inputStream에서 inputStream 크기만큼 읽어 versionBuffer에 저장한다.
byteArray2Int에 전달한 버퍼를 통해 (복호화) 버전을 얻을 수 있다.

    private int byteArray2Int(byte[] bytes) throws IOException {
        int length = Math.min(bytes.length, 4);
        if (length < 1) {
            throw new IOException("version length error");
        } else {
            int value = 0;

            for(int i = length - 1; i >= 0; --i) {
                value = (value << 8) + (bytes[i] & 255);
            }

            return value;
        }
    }

byteArray2Int에서는 최대 4바이트로로 범위를 지정하고 맨 뒤에서부터 앞으로(리틀엔디안) 바이트를 8비트씩 이동 시킨 뒤 합쳐 int로 만든다.

리틀엔디안은 바이트 순서의 한 방식으로, 최하위 바이트가 앞에 위치한다. 반대로 빅엔디안은 최상위 바이트가 앞에 나온다. 엔디안 사이의 통신에서는 문제가 되지 않지만 다른 엔디안끼리 통신하는 경우 문제가 발생한다. Intel가 리틀 엔디안 채택하고있다.

위 함수를 통해 브레이크포인트를 걸어보니 1이라는 값이 도출되고 있다.

이후 버퍼 크기가 16바이트가 맞는지 확인하며 version에 해당하는 level 값을 지정한다.

로그: DecryptImageRequest decryptHead version:1, level:3

public class DecryptFilter {
    private static final String TAG = DecryptFilter.class.getSimpleName();

    public DecryptFilter() {
    }

    public static InputStream buildStream(InputStream ins, EncryptLevel level, byte[] iv, byte[] key) throws NoSuchPaddingException, NoSuchAlgorithmException, InvalidAlgorithmParameterException, InvalidKeyException {
        byte[] encryptKey = key;
        byte[] encryptIv = iv;
        if (level == EncryptLevel.ChaCha20) {
            byte[] chacha20Key = new byte[32];
            System.arraycopy(key, 0, chacha20Key, 0, 16);
            System.arraycopy(key, 0, chacha20Key, 16, 16);
            encryptKey = chacha20Key;
            byte[] chacha20Iv = new byte[12];
            System.arraycopy(iv, 0, chacha20Iv, 0, 12);
            encryptIv = chacha20Iv;
            if (VERSION.SDK_INT < 28) {
                L.d(TAG, "use ChaCha20InputStream to encrypt image");
                return new ChaCha20InputStream(ins, chacha20Iv, chacha20Key);
            }
        }

        SecretKeySpec keySpec = new SecretKeySpec(encryptKey, level.getAlgorithm());
        Cipher cipher = Cipher.getInstance(level.getTransformation());
        cipher.init(2, keySpec, new IvParameterSpec(encryptIv));
        CipherInputStream cipherInputStream = new CipherInputStream(ins, cipher);
        return cipherInputStream;
    }
}

buildStream함수에서 메타데이터를 바탕으로 실제 복호화 스트림을 만든다.

함수 내부에서 암호화 레벨이 ChaCha20가 아닌 AES이므로 if문은 거치지 않고 바로 CipherInputStream를 통해 InputStream를 평문처럼 읽을 수 있게 처리한다.

CipherInputStream의 상속 구조는 CipherInputStream > FilterInputStream > InputStream 형태로, InputStream에 암호 알고리즘을 물려서, 실시간 복호화/암호화된 스트림을 아주 쉽게 쓸 수 있게 해주는 클래스다.

public enum EncryptLevel {
    NONE(1, "", ""),
    ChaCha20(2, "ChaCha20", "ChaCha20/NONE/NoPadding"),
    AES(3, "AES", "AES/CBC/PKCS5Padding"),
    GCM(4, "AES", "AES/GCM/NoPadding");

    private final int level;
    private final String algorithm;
    private final String transformation;

    private EncryptLevel(int level, String algorithm, String transformation) {
        this.level = level;
        this.algorithm = algorithm;
        this.transformation = transformation;
    }

    public static EncryptLevel valueOf(int level) {
        switch (level) {
            case 1:
                return NONE;
            case 2:
                return ChaCha20;
            case 3:
            default:
                return AES;
            case 4:
                return GCM;
        }
    }

    public int value() {
        return this.level;
    }

    public String getAlgorithm() {
        return this.algorithm;
    }

    public String getTransformation() {
        return this.transformation;
    }

    public String toString() {
        return "EncryptLevel{level=" + this.level + ", algorithm='" + this.algorithm + '\'' + ", transformation='" + this.transformation + '\'' + '}';
    }
}

암호화 알고리즘별로 값, 알고리즘 문구, transformation 문자열(AES/CBC/PKCS5Padding 등)을 관리된다.
Tuya에서는 level 3에 해당하는 AES 알고리즘을 사용하고 있다.

[pachuho]

Signed URL 분석

AWS에서 채택하고 있는 URL은 단순 URL 아닌 서명된 URL이다.
이는 AWS 자원에 대해 일시적이고 제한된 접근을 허용하는 보안 기법이다.
서명된 URL에는 접근 권한, 유효 시간 및 보안 서명이 포함되어 있어 보안적으로 안전하게 외부 접근을 제어할 수 있다.

개요에 기입한 url을 분석해보면 아래와 같다.

// 접근 URL
https://xxx.s3.ap-northeast-2.amazonaws.com/exxx-tuya20602b52adf3cee5/detect/1744253619.jpeg?

// AWS 서명 생성에 사용하는 알고리즘 (AWS4-HMAC-SHA256 표준 사용)
X-Amz-Algorithm=AWS4-HMAC-SHA256&

// 서명을 생성한 날짜와 시간 (UTC)
X-Amz-Date=20250411T144039Z&

// 서명에 포함된 헤더 정보 (현재 host만 포함)
X-Amz-SignedHeaders=host&

// 해당 URL의 유효한 접근 가능 시간 (초 단위로, 3600초 = 1시간)
X-Amz-Expires=3600&

// AWS 접근 키 정보로, 접근할 서비스 및 리소스의 범위를 제한함
X-Amz-Credential=AKIA4MTWMRQDMDVZXXXX%2F20250410%2Fap-northeast-2%2Fs3%2Faws4_request&

// 위 정보들로 계산된 실제 서명의 해시값 (이 값을 통해 요청 유효성 검사)
X-Amz-Signature=4a612c4bf9eb4ccd512d95630381a329d8fbf9f33b9d0ee9ca7354cd2394xxxx@

// AES 복호화에 사용되는 암호화 키
3a0bb89cf7bexxxx

AWS Signed URL은 클라이언트가 이미지에 접근을 시도할 때 AWS가 부여한 Credential, Date, Expires, Algorithm 등의 정보를 이용하여 서명(Signature)을 생성한다.클라이언트가 URL을 통해 리소스에 접근하려고 할 때, AWS는 URL의 파라미터들(알고리즘, 요청 날짜, credential 등)을 활용해 동일한 서명을 다시 생성하여 맞는지 비교한다.
서명이 일치하고 URL 내 최초로 설정한 X-Amz-Expires 시간이 만료되지 않았다면 요청은 유효하며, 이미지를 클라이언트에게 제공한다.
이 방식을 통해 URL은 특정 유효 기간 동안만 일시적으로 유효한 접근 권한을 허용하여 AWS 자원 보안을 보장한다.

[pachuho]

정리

Tuya SDK를 사용한 카메라 기기의 이미지 접근 및 표시 과정은 다음과 같은 절차를 통해 보안을 유지하는 것으로 보인다.

1. 사용자가 접근 가능한 카메라 기기로부터 S3 스토리지 URL을 가져온다. 이 URL은 두 부분으로 구성되며, '@' 문자를 기준으로 앞쪽은 이미지의 위치를 나타내는 URL이고 뒤쪽은 이미지 복호화에 사용될 키이다.

2. URL은 AWS의 Signed URL 방식으로 생성된 것으로 보이며, 특정 만료 시간(X-Amz-Expires) 및 접근 권한 관련한 자격(X-Amz-Credential, X-Amz-Signature)을 담고 있다. 이를 통해 URL이 지정된 유효기간 내에만 일회성 접근이 가능하도록 보장하여 외부에서의 무제한적 URL 접근을 차단한다.

3. URL을 통해 클라우드에 요청한 이미지 데이터는 AES 대칭 키 암호화 알고리즘을 이용해 추가 암호화된 상태로 전달된다. 데이터 앞 부분에 암호화 메타 데이터(암호화 버전, IV(Initialization Vector), 암호화 레벨 정보 등)가 포함되어 전송되며, 애플리케이션 측에서 이 메타데이터를 파싱하여 복호화 과정에 사용한다.

4. SDK 내부에서는 전달된 키와 추출된 메타 데이터를 바탕으로 CipherInputStream을 이용해 실시간으로 암호화된 이미지 데이터를 복호화하여 메모리에 로딩한 뒤, 최종적으로 UI에 표시한다. 이때 사용되는 CipherInputStream은 설정된 필터에 따라 데이터 스트림을 순차적으로 분석하며 메모리상에서 안정적으로 해독 과정을 수행한다.

결론적으로, Tuya SDK가 제공하는 이미지의 로딩 과정은 일회성 AWS Signed URL 기법에 기반한 제한적 접근 권한 및 AES-암호화된 데이터 전송을 통해 2중 보안을 제공하며, 특정 암호화 메타 데이터를 활용하여 최종적으로 안전하게 이미지를 복호화하여 사용자에게 노출하는 구조로 구성되어 있다.