No padding for AES cipher in Java Card - cryptography

Question

In JavaCard 2.2.2 API, I can see that some symmetric ciphers are implemented with a padding mode, for example:
Cipher algorithm ALG_DES_CBC_ISO9797_M1 provides a cipher using DES in
CBC mode or triple DES in outer CBC mode, and pads input data
according to the ISO 9797 method 1 scheme.
But for the AES cipher, there is no padding mode that is available (ALG_AES_BLOCK_128_ECB_NOPAD and ALG_AES_BLOCK_128_CBC_NOPAD).
So how explain that it's not supported for this algorithm?
Are these padding methods vulnerable to known attacks using AES?

Answer 1

If other padding modes are available depends on the Java Card API you are using as well as the implementation details for the specific Java Card.
Later API's have:
a new getInstance method which can be used with PAD_PKCS5;
additional constants such as ALG_AES_CBC_PKCS5.
The special getInstance method was added because of the explosion of modes and padding methods.
Older API implementations may indeed not have these methods, but please again check availability.
AES itself is a block cipher. The different modes such as CBC use a cipher and a padding - so CBC_AES_PKCS7PADDING would be more logical in some sense. As a block cipher, AES is therefore not vulnerable to padding oracle attacks.
CBC on the other hand is vulnerable against padding oracle - and other plaintext oracle - attacks. So you should protect your IV and ciphertext with e.g. a AES-CMAC authentication tag if you need protection against these attacks.
That's however not a reason why the padding modes were not included. The different padding modes are certainly present now.

Answer 2

Not necessarily - it only means, that this algorithm does not automatically pad input data. You have to do it by yourself (probably pad it to multiples of 16 bytes, because this is what AES needs).
So how explain that it's not supported for this algorithm?
I don't know for sure, but note that there are several ways of doing this and maybe author decided that you have choose most suitable padding style for you.
If case you want to know more about padding, consider this example:
You have to encrypt a word "overflow" with AES.
First, you have to convert it to byte form, because this is what AES operates on.
ASCII encoded string "overflow" is
"6F 76 65 72 66 6C 6F 77 00"
(last byte is string terminator, AKA \0 or null byte)
Unfortunately, this is also insufficient for pure AES algorithm, because it can OLNY operate on whole blocks of data - like 16 byte block of data.
This means, you need 16-9=7 more bytes of data. So you pad your encoded string to full 16 bytes of data with null byte for example. Result is
"6F 76 65 72 66 6C 6F 77 00 00 00 00 00 00 00 00"
Now you choose your encryption key and encrypt data.
After you decrypt your data, you receive again
"6F 76 65 72 66 6C 6F 77 00 00 00 00 00 00 00 00"
And now the crux of the matter: how do you know, which bytes where originally in your string, and which are padding bytes?
In case of en/decrypting strings this is very simple because string (almost) always ends with null byte, and never have multiple consecutive null bytes at the end. So it's easy to determine where to cut your data.
More information about styles of "crypto-padding" you can find here: https://en.wikipedia.org/wiki/Padding_%28cryptography%29#Byte_padding